Hacker News Reader

Comment by sdcfgy | Hacker News Reader

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.

View on 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.

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 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.

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.

No it's more the "what the hell are people doing to make their lives difficult?" argument.

To be fair, they were just sharing their experience. I don’t recall them saying anything close to your interpretation.

Vanilla vim sure, no problem. But try to add syntax highlighting and code completion plugins.

Reply on news.ycombinator.com