Comment by sdcfgy
8 hours ago
I've used vim since the first time it appeared in Debian repos. I have been told a thousand times that NeoVim is better, more modern and solves many (conveniently never cited) issues. I just ignored it and carried on. Feeling terribly vindicated at this point as it's a feature I use regularly and have no idea that it would be an issue in NeoVim.
I've used vi and nvi and (now) vim, and tried neovim, but :! is broken and “Conform to POSIX vi” is one of their “Non-goals”.
POSIX vi is so barebones that nobody* wants that.
Bare vi does not have windows, visual selection mode, multiple level undo, color schemes, etc.
NVim wants to improve some defaults, which cannot be done if it is beholden to all legacy code. That being said, I still think this specific undo example is insane.
Nvim's `:!` behaviour was a deliberate design decision, which is one of the reasons I just stick with Vim9.
What's the issue? I use nvim and regularly use :! and haven't noticed an issue.
2 replies →
I've never used NeoVim because Vim has been good enough.
Vim is good enough now. The reason I switched to NeoVim in like 2015 is because it had async plugin support. With vanilla Vim at the time, if you had a lot of plugins it could get pretty slow and stuttery pretty quickly.
Vanilla Vim added it in 2016 I think, but by that time I had already fully switched to NeoVim and it didn't seem worth it to me to switch.
*vimdicated
[dead]
I used neovim because it felt way faster by default. I think treesitter runs circles around what classic vim is using to highlight syntax. That said, I never used both beyond basics, thus no horror stories either.
I haven't noticed any performance issues in vim to start with. It was fast on a 75MHz pentium for me. The syntax highlighting, same. No issues. I don't always use that though because I can't be bothered to set up anything much past the basic config.
At one point vim lacked asynchronous plugins. If a plugin was running a builder or linter it locked the editor up (from what I recall).
That fell apart when people wanted vim to do some more modern IDE kind of things like all the “… on save” stuff (build on save, test, lint, etc). I think LSP support is native in neovim as well.
I believe vim merged asynchronous plugin support a while back though, so I’m not sure how different they really are anymore.
3 replies →
IIRC vim became really slow with the combination of large source files (thousands of lines of code) and language server plugins (e.g. code completion and live error squiggles).
3 replies →
Tree-sitter is more performant for sure, and its potential for easier text objects is nice. However, Vim's syntax engine is more than good enough for non-complex highlighting (and many people don't want complex highlighting) and, while I don't have enough tree-sitter knowledge to explain this myself, I've seen examples of Lua versions of Vim plugins where tree-sitter is unable to handle some of the regex-based text objects present in the vimscript version.
As far as really cool uses for tree-sitter go, ast-grep is a fantastic tool. Of course it's a standalone program, so it doesn't need nvim to make use of it.
If one really needs an undo in today's day and age, use git.
It’s two different dimensions in this case. VCS doesn’t preserve your local history (in JetBrains’ terms) of changes (and it wasn’t meant to by design)
I don't use git. I actually have something still using RCS.
Ok, I’ve gotta hear this. For what? I haven’t touched rcs since we upgraded to cvs. Is it still unusually good at something today?
Someone didn't read the part about wanting a humane interface