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.
It doesn't support interactive commands. For example if you run a command that asks for input before finishing, it gets swallowed.
It does something using neovim's internal terminal mode rather than use the file descriptors it was called with. Most commonly this breaks when a command produces an interactive prompt or uses a pager.
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.
That seems like solving the wrong problem.
Just run make from another terminal...
It was a real problem, but as GP already mentioned, Vim has integrated some version of it since Vim 8 (2016), probably at least somewhat motivated by NeoVim (forked 2014).
https://lwn.net/Articles/713114/
I hadn't noticed.
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).
I had a C program that was a single file 140,000 lines long back then. No issues.
Ah yes, the "I've never had this problem so obviously no one else could have possibly had it" argument.
I was using vim-enhanced as red hat-based distro installed it. No customization. No customization of nvim either.
I often use vim or nvim on disposable machines, so persistent undo is something very low on my list of things I want.
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