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

On Fri, Dec 03, 2021 at 03:31:58AM +0300, Andrey Popp wrote:
> Ah, forgot about another thing — this patch changes how it determines
> what to eval — it always sends code from the start of the buffer to
> the current `to`. I actually think this is a good thing when you just
> press Enter (you really want all previously defined bindings to be
> available) but for visual mode — maybe it should send exactly what was
> selected...

I think the enter behavior in this implementation makes sense. It
greatly reduces the amount of visual selections needed.

About the visual selection, I think your suggestion about sending
exactly the selection is the most reasonable thing to do. It could be
handy for example when there's an expensive computation somewhere in the