Whoops, replied directly to you, not to the mailing list. Seems like I
don't know how to use sr.ht either :D The message follows:

Hi, thank you for the patch!

On Sun, Nov 10, 2024 at 05:36:26PM -0800, ~deriamis wrote:
> From: Ryan Egesdahl <ryan@deriamis.net>
>
> The current build method will correctly link with `libcbqn`, but only
> if `LD_LIBRARY_PATH` is set (which, incidentally, `build.bqn` doesn't
> set properly). However, we can just use `rpath` in a cross-platform
> way to avoid the need. This benefits end-users by making sure they
> don't need to move or copy `libcbqn` to where ever `bqnlsp` is
> located.

Hi.

Thanks for the contribution, this totally makes sense. I am a NixOS user
myself nowadays, so I probably now can be of help of getting bqnlsp to
work with Nix more nicely. I've just haven't had the time to delve into
it yet.

--
Antti

LGTM! Applied.

--
Antti

Quoting Ian M. Jones (2022-05-12 02:05:57)
> The referenced ticket did not get a comment appended, and did not get
> closed as "IMPLEMENTED".
> 
> Could it be because the tracker is private?

I tried creating a public repo with a public tracker (I didn't touch the
permissions at any point) and it still does not seem to work:
https://sr.ht/~detegr/public_test/

--
Antti

It is documented[1] that one should be able to manipulate todo tickets
via commit messages. However, in my test repository[2] I'm unable to get
it working.

AFAICT the tracker and git repo should be linked as instructed and I
should have all the required permissions as I'm the one that created the
tracker and the repository. Is this some old documentation, is the
feature broken, or am I just dumb and have missed something essential?

[1]: https://man.sr.ht/git.sr.ht/#referencing-tickets-in-git-commit-messages
[2]: https://sr.ht/~detegr/test

-- 
Antti

Thanks, pushed to master.

-- 
Antti

On Tue, Dec 07, 2021 at 05:33:32PM +0300, Andrey Popp wrote:
> Once we see an error returned from CBQN we set diagnostics via
> `vim.diagnostic` API. This helps to see which line contains the error.
> 
> The diagnostic set is "ephemeral" as it will be cleared (or replaced
> with another one) once we eval another piece of code.
> ---
> 
> Let me know what you think! I've found this useful to quickly find an offending
> line. Would be cool if CBQN reported a column as well...

I think it's worth having. Usually I get the errors on the same line I'm
evaluating so I had not thought about needing this info but as it is
availabe, I don't see why we wouldn't do this.

Hi.

On Tue, Dec 07, 2021 at 05:33:30PM +0300, Andrey Popp wrote:
> This changes command names to be prefixed with `:BQN` for better
> discovery (completion in command mode).
> 
> Then this introduces plug mappings and automatically maps them to
> 
> - `<CR>` evals, till the line (or range), as previously
> - `<leader>bf` evals the whole file
> - `<leader>bc` clears output after the line (or range)
> ---
> 
> The changes as we've discussed before.

Hi.

On Sun, Dec 05, 2021 at 04:26:29PM +0300, Andrey Popp wrote:
> Hi,
> 
> On Sun Dec 5, 2021 at 10:35 AM MSK, Antti Keränen wrote:
> > On Sat, Dec 04, 2021 at 05:16:00PM +0300, Andrey Popp wrote:
> > > The set of available command has changed, first we have the following
> > > commands to eval BQN expressions:
> > > 
> > >     :EvalBQNTillLine
> > >     :EvalBQNRange
> > >     :EvalBQNFile
> > > 

On Sat, Dec 04, 2021 at 05:16:00PM +0300, Andrey Popp wrote:
> This commit makes nvim-bqn use virtual lines feature of neovim 0.6.0
> show output of running BQN expressions.
> 
> The set of available command has changed, first we have the following
> commands to eval BQN expressions:
> 
>     :EvalBQNTillLine
>     :EvalBQNRange
>     :EvalBQNFile
> 
> and then a set of commands to clear output:
> 
>     :ClearBQNAfterLine