Under what use cases should I prefer Neovim over vim? I’m glad we have so many different terminal editors but it is not clear to me what the differences are. When I moved back to Linux I ditched VS Code for my uses (light coding and mostly prose writing) and have been fine, but my needs are very modest.
For me the killer feature is https://github.com/vscode-neovim/vscode-neovim because I pretty much have to use some IDE, for accessibility reasons I pretty much need vi keybindings (don’t like taking my hands off home row) and most IDE vi emulation plugins are less accurate than this one.
The other alternatives for me would have been emacs with evil-mode or neovim configured with lots of plugins to make them into passable IDEs.
The ability to customise it in Lua is also nice. I didn’t want to learn vimscript.
There’s a lot more stuff that supports neovim but not vim, than stuff that supports vim9 but not neovim. If you don’t care about that stuff, or any of the more advanced terminal support, then it’s a wash. But if you want to go shopping around for most of the more recent plugin development, neovim.
I’ve read so many vim articles about how you need to keep your hands on the home row, how the mouse is inefficient, how if you want the mouse you just aren’t good enough with vim, etc. Whereas the actual developers of neovim are like “no that’s stupid, use the damn mouse”
(I know vimnilla had mousemode but it didn’t have right-click menus or input_mouse())
I’m definitely against reflexive anti-mouse sentiment and I have mouse support turned on in my own neovim config. That said, I do find that I rarely use it, and generally navigate around purely by keyboard in neovim.
gx in Normal mode calls vim.ui.open() on whatever is under the cursor, which shells out to your operating system’s “open” capability (e.g. open on macOS or xdg-open on Linux). For instance, pressing gx on a URL will open that URL in your browser.
The linked PR lists the contrast ratios for the new color scheme, all of which (except for comments selected in Visual mode) exceed the WCAG contrast ratio requirement of 4.5:1.
Yeah, much effort was put into using quantifiable measuring to be at least somewhat sure that the final result is “good enough”.
When people talk about “higher/lower contrast”, they might mean different things. During default color scheme creation the contrast ratio of background vs foreground colors was used. It compares “lightness contrast”, has quite widespread definitions and requirements. Funnily enough, for me personally, the default color scheme has too much contrast with this definition (dark colors are too dark, light colors are too light).
The other direction people might think about contrast is how much hue (“true color”) varies. Here I agree that usage of green-cyan-blue as main text colors is not the best. However, using only these hues was a fixed requirement for PR to be merged (initially it was even only cyan and green).
They probably mean the contrast between colours (just assuming), and how distinct they are from each other. But I do personally like the new theme a lot more.
Oh good, it looks like using luarocks was removed so it can be built without internet more easily.
Under what use cases should I prefer Neovim over vim? I’m glad we have so many different terminal editors but it is not clear to me what the differences are. When I moved back to Linux I ditched VS Code for my uses (light coding and mostly prose writing) and have been fine, but my needs are very modest.
Write plugins & configuration in Lua instead of Vimscript, is the main difference. Also smoother integration of LSPs and tree-sitter.
Nice thank you for that explanation. My usage of LSPs is light - I use
goplsvia ALE. I can see vimscript getting tedious for complicated plugins.If anything it has better/more sensible out of the box defaults http://neovim.io/doc/user/vim_diff.html#nvim-defaults
For me the killer feature is https://github.com/vscode-neovim/vscode-neovim because I pretty much have to use some IDE, for accessibility reasons I pretty much need vi keybindings (don’t like taking my hands off home row) and most IDE vi emulation plugins are less accurate than this one.
The other alternatives for me would have been emacs with evil-mode or neovim configured with lots of plugins to make them into passable IDEs.
The ability to customise it in Lua is also nice. I didn’t want to learn vimscript.
Doesn’t really matter for you, use whatever.
There’s a lot more stuff that supports neovim but not vim, than stuff that supports vim9 but not neovim. If you don’t care about that stuff, or any of the more advanced terminal support, then it’s a wash. But if you want to go shopping around for most of the more recent plugin development, neovim.
Every mouse improvement in neovim makes me giggle
I’m not sure why this is funny.
I’ve read so many vim articles about how you need to keep your hands on the home row, how the mouse is inefficient, how if you want the mouse you just aren’t good enough with vim, etc. Whereas the actual developers of neovim are like “no that’s stupid, use the damn mouse”
(I know vimnilla had mousemode but it didn’t have right-click menus or
input_mouse())I’m definitely against reflexive anti-mouse sentiment and I have mouse support turned on in my own neovim config. That said, I do find that I rarely use it, and generally navigate around purely by keyboard in neovim.
I really like being able to define custom contextual mouse menus, though I haven’t really gone deep in using that yet.
Apparently shell programs are supposed to live in the ‘80s where terminals don’t support mice whatsoever?
Excited to see the tree-sitter inspector get integrated after it looks like the old plugin was deprecated.
That sounds really handy
That was already there beforehand, but that was implemented via NetRW instead of being built-in.
It’s ironic that they praise the new cotorscheme for accessibility when it has much lower contrast than the old one.
The linked PR lists the contrast ratios for the new color scheme, all of which (except for comments selected in Visual mode) exceed the WCAG contrast ratio requirement of 4.5:1.
Yeah, much effort was put into using quantifiable measuring to be at least somewhat sure that the final result is “good enough”.
When people talk about “higher/lower contrast”, they might mean different things. During default color scheme creation the contrast ratio of background vs foreground colors was used. It compares “lightness contrast”, has quite widespread definitions and requirements. Funnily enough, for me personally, the default color scheme has too much contrast with this definition (dark colors are too dark, light colors are too light).
The other direction people might think about contrast is how much hue (“true color”) varies. Here I agree that usage of green-cyan-blue as main text colors is not the best. However, using only these hues was a fixed requirement for PR to be merged (initially it was even only cyan and green).
They probably mean the contrast between colours (just assuming), and how distinct they are from each other. But I do personally like the new theme a lot more.