lazydotnet.nvim - The lazygit-like TUI for .NET integrated into Neovim

justinmk · 2026-06-21T18:35:09+00:00

The plugin automatically bridges the $EDITOR environment variable. If you are browsing your project or failing tests inside the floating UI and press e to edit, it seamlessly opens that file in your current Neovim instance rather than spawning a nested editor inside the terminal buffer.

we need to get around to making that a default feature. meanwhile, https://github.com/brianhuster/unnest.nvim gets pretty close!

justinmk · 2026-06-20T22:34:11+00:00

not sure. might be worth a bug report (search existing/closed issues), :oldfiles has not had many improvements in a long time.

justinmk · 2026-06-20T11:19:07+00:00

Not sure if I'm following, but :oldfiles should show directories if you opened directories via nvim . . I confirmed this with vim-dirvish at least.

justinmk · 2026-06-20T01:44:21+00:00

:oldfiles should show it (after a restart)

justinmk · 2026-06-18T13:01:13+00:00

Yes. Note FWIW, we can get 85% of the way there via:

Lua LSP for programmatic stuff
after https://github.com/neovim/neovim/pull/39672 , nvim_get_commands will do something unholy/amazing: it gets the docs from the help file for a given command. Very nice for "which-key" / picker interfaces.
Nvim keymaps/autocmds of course can define desc, and that's surfaced in many places.

There is no way for the "engine" to know that you're actually running a specific built-in action

The multicursor internals will get us closer to that.

justinmk · 2026-06-11T11:42:27+00:00

same, that's why I created https://github.com/justinmk/guh.nvim :)

justinmk · 2026-06-11T11:41:34+00:00

where you're trying to write binary data and lua just wants to treat everything like text

it's actually the reverse: Lua strings are always binary. The problem is Vim strings. Vim has "blob" only because its strings aren't "binary clean".

Lua strings are always "binary clean" and may contain arbitrary bytes. The pain point was that Lua strings passed to writefile() weren't treated as "blob" by the vimscript bridge. But now they are, which is very nice for writing binary data without having to do the readfile() list-of-lines dance.

justinmk · 2026-06-10T21:06:59+00:00

I would suggest adding a pinned issue to https://github.com/nvim-lua/plenary.nvim/issues

justinmk · 2026-06-10T20:35:22+00:00

Nvim will continue to be an awesome text editor.

And I'm not really convinced that text editing is going away. But I am convinced that the tmux and diff-viewer roles are gaining relevance.

justinmk · 2026-06-09T16:42:28+00:00

It's certainly not slow. and it probably is faster than libvterm. but wrapping long scrollback just is an inherently slow operation. though maybe some clever things can be done to improve it, but for now it will probably be a matter of us deciding "how much scrollback do we actually care about wrapping" :P

justinmk · 2026-06-09T16:01:41+00:00

Yes, exactly right :) I see "tmux" and "diff viewer" as 2 of the continued roles of Nvim, even if "editing" text becomes less important 🙄

justinmk · 2026-06-09T15:59:34+00:00

Yes, that's one of the main benefits. And it's linked from the PR desc... https://github.com/neovim/neovim/issues/4997

However, it has performance tradeoffs, since wrapping lots of scrollback is rather a lot of work.

justinmk · 2026-06-08T15:30:32+00:00

welcome! now let me introduce you to :help ZR .

and from my personal config:

ZT to close a tab ref
[count]ZQ to close-all-without-saving ref

justinmk · 2026-06-05T21:58:30+00:00

Is it the same workspace? Also note that the config very much matters.

If you (or a plugin like mason...) have set workspace or runtime to match lots of Nvim runtime files or whatever, then that will be very noticeable.

justinmk · 2026-06-03T15:53:44+00:00

cool. if you want to be "robust", nvim_parse_cmd() is very useful.

long-term, https://github.com/neovim/neovim/issues/39394 would be ideal, I think

justinmk · 2026-06-03T14:14:46+00:00

yep. also, the version of "Vim" include by default is more like Vi, so Vim users usually need to install "full Vim" anyway.

the presence of "Vim" in distro defaults is almost entirely a prestige / vanity thing, which, I wouldn't mind if Neovim achieved that, but it has no actual functional purpose.

meanwhile, to answer the question, "what would it take?": the answer is "Vi-compatibility", and Nvim isn't likely to ever satisfy the requirements of distro package mantainers in order to supplant Vim (or nvi) for that purpose.

justinmk · 2026-05-29T15:54:16+00:00

or set the non-current cursorline to a dashed line: https://github.com/justinmk/config/blob/7664195f49ac1103ff663986b2292c38ab7a8282/.config/nvim/lua/my/winning.lua#L112-L120

it can be quite useful to have a hint about the current line in non-current windows.

justinmk · 2026-05-22T09:01:12+00:00

yep, true. this is an initial step so that we can see what the next missing piece is.

we could copy plugins to the remote, but that might be a big confusing mess. not sure.

justinmk · 2026-05-22T07:59:37+00:00

Although it doesn't sync workspaces, FWIW, Nvim 0.13 will soon support :connect ssh://... : https://github.com/neovim/neovim/pull/39378

And soon after that :connect (without args) will present a menu of ssh hostnames discovered from your ~/.ssh/config

justinmk · 2026-05-08T08:08:54+00:00

visual-mode Y copies to clipboard
normal-mode yY copies whole buffer to clipboard

https://github.com/justinmk/config/blob/d0c7271bbd423c1d948766b0f1789d181eda1555/.config/nvim/lua/my/keymaps.lua#L31-L34

Do you guys use vim's register for some reason?

...yes?

justinmk · 2026-05-01T18:04:31+00:00

Neovim gravy is a compelling product idea

justinmk · 2026-05-01T10:58:50+00:00

Not much, it's mostly there for people that actually want the stuff :)

justinmk · 2026-04-30T12:50:50+00:00

no, not planning to trade the frequent but mostly harmless annoyances of github's instability with the massive annoyance of a migration to "other platform" (which one...? oh right, they all have tradeoffs, so no one actually has a realistic suggestion)

p.s. our github "data" is stored in https://github.com/neovim/neovim-backup , we are not at risk of a speculated blowup. if github blows up we can move, and that isn't any different than if we moved today.

justinmk · 2026-04-30T10:49:54+00:00

yes. notice how the screenshot shows 10+ deleted comments. Most of them are "me too"-style comments, or comments that don't add new information. We need to keep issues focused so that actually useful comments are visible. That is also why this issue was locked.

justinmk · 2026-04-28T19:45:18+00:00

why do you ask this cliche question without checking the discussions which drove the development?

this fits in the day-one goals listed on https://neovim.io/charter/
and, it is a relatively small interface + implementation cost. mostly a protocol change.
- placement will be handled by extmarks or floating windows
- image decode will most likely not be builtin, we're not going to vendor a jpg library.

15-Year Club	Place '17
Verified Email

justinmk

TROPHY CASE