From Antti Keränen to ~detegr/bqnlsp
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
From Antti Keränen to ~detegr/nvim-bqn
LGTM! Applied. -- Antti
From Antti Keränen to ~sircmpwn/sr.ht-discuss
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
From Antti Keränen to ~sircmpwn/sr.ht-discuss
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
From Antti Keränen to ~detegr/nvim-bqn
Thanks, pushed to master. -- Antti
From Antti Keränen to ~detegr/nvim-bqn
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.
From Antti Keränen to ~detegr/nvim-bqn
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.
From Antti Keränen to ~detegr/nvim-bqn
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 > > >
From Antti Keränen to ~detegr/nvim-bqn
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
From Antti Keränen to ~detegr/nvim-bqn
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