Hacker News Reader

Comment by stewbrew | Hacker News Reader

I understand why they started neovim, but don't think the split between vim 8 of today and neovim is a good thing. Makes me think of emacs vs xemacs but worth because they use slightly different dialects of vimscript (closures, currying in vim 8, different api for asynchronous calls). I personally wish they'd meet on some common, standardized ground. This would require both parties to accept they are not alone though.

Edit: I realize that "Vim 8 features: partials, lambdas." might solve part of my problem.

View on HN

> I personally wish they'd meet on some common, standardized ground. This would require both parties to accept they are not alone though.

Yeah, not going to happen. ViM's author is remarkably hostile to the efforts of NeoVim and the ideas it brings forth.

Can you back up this claim? I think it's not true and authors of both projects respect each other. They simply have different views regarding backwards compatibility etc.

I think 'hostile' is a bit harsh. I'd say 'infinitely reticent to large changes'. All the neovim authors wanted, was a list of blockers needed to merge their async patch. Bram would never give them that, always coming up with one more change. I've seen this pattern of infinite reluctance before, especially when communities depend heavily on one maintainer. its not about async and the specific semantics of the patch after a certain amount of time, it's about deeper issues like project vision, control, and perhaps trust. https://groups.google.com/forum/m/#!topic/vim_dev/-4pqDJfHCs... https://geoff.greer.fm/2015/01/15/why-neovim-is-better-than-...,

All they wanted was to fork the project to "clean up" the code in ways they wanted, manage the community themselves, etc. It wasn't like all their patches were flawless and Bram just wouldn't accept them.

Just dumping any old code into a project the first time it's demanded is a sign not of enlightened maintenance but of gross negligence. It's good if there's a lot of feedback on patches, it's not some kind of aggression.

The diffwrence in performance is hhuuuugggee!

Vim lags on my project, nvim doesnt! Quadcorei5, 16hb ram!

What are you doing that makes Vim lag? In my experience (on much weaker hardware) it only lags noticeably when you do wildly unusual stuff, e.g. huge files or files with huge lines.

On an old netbook (remember those?) Vim would lag just entering text in insert mode when I was editing LaTeX files (and only LaTeX files as far as I could tell). Slowness of LaTeX syntax highlighting is a known problem (the help files have a section called tex-slow). Trying all the suggestions there didn't speed things up enough for me. I tried editing without syntax highlighting for a while (this did work and completely solved the lag), but eventually just switched to Emacs.

Editing latex(colors, parens, higjlighting, syntax check)

Scala (700 lines/file)

Managed to do more with nvim - yet to try syntactic again, thatll be the real test) but so far amuch more stable experience movement wise. (the files i work on are huge and im tasked with refactoring, so i cant avoid the hugeness)

That's strange. Do you have some unusual plugins?

Syntactic and highlighting unusual?

Reply on news.ycombinator.com