Thread

On caring for user data: NeoVim caused Vim undo files to be deleted

384 points · 346 comments · jandeboevrie

sdcfgy · 1790523505 · focus · HN ↗
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.
1. WesolyKubeczek · 1790523829 · focus · HN ↗
  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.
  1. sdcfgy · 1790524012 · focus · HN ↗
    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.
    everforward · 1790525882 · focus · HN ↗
    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.
    sdcfgy · 1790527392 · focus · HN ↗
    That seems like solving the wrong problem.
    Just run make from another terminal...
    loeg · 1790528036 · focus · HN ↗
    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).
    <a href="https://lwn.net/Articles/713114/" rel="nofollow">https://lwn.net/Articles/713114/
    sdcfgy · 1790529780 · focus · HN ↗
    I hadn't noticed.
    flohofwoe · 1790526234 · focus · HN ↗
    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).
    WesolyKubeczek · 1790527154 · focus · HN ↗
    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.
    sdcfgy · 1790527336 · focus · HN ↗
    I had a C program that was a single file 140,000 lines long back then. No issues.
    kelnos · 1790548771 · focus · HN ↗
    Ah yes, the "I've never had this problem so obviously no one else could have possibly had it" argument.
    sdcfgy · 1790581351 · focus · HN ↗
    No it's more the "what the hell are people doing to make their lives difficult?" argument.
    rmwaite · 1790601440 · focus · HN ↗
    To be fair, they were just sharing their experience. I don’t recall them saying anything close to your interpretation.
    flohofwoe · 1790582768 · focus · HN ↗
    Vanilla vim sure, no problem. But try to add syntax highlighting and code completion plugins.
  2. sodapopcan · 1790532088 · focus · HN ↗
    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.

Open on Hacker News to reply ↗

Unofficial Hacker News client; not affiliated with Y Combinator.