I prefer Vim’s approach of using JSON for communicating with external jobs instead of using Messagepack like Neovim does. I’m also not very partial about inventing a new binary format as a vimimfo replacement.
It is my understanding that Neovim wasn’t available on Windows for quite a while. I’m all for shedding features in order to facilitate building new ones, it might take Neovim in interesting new directions, but then the new project should not be considered a drop-in replacement for the old one.
(I even kind of like VimScript, despite its weirdness.)
I’m also not very partial about inventing a new binary format as a vimimfo replacement.
viminfo is an ad-hoc unstructured format. shada is trivially parsable (and stream-able), because it’s just msgpack. It’s misleading to call it a “new binary format”, it’s just plain old msgpack with some sentinel values for guaranteed round-tripping to/from VimL.
It doesn’t make sense to prefer viminfo, which isn’t a format at all.
I’d much rather use vimscript than Python for scripting vim. Vimscript is no stranger a language than many other domain-specific languages out there. And I’d definitely rather configure using vimscript than Python or elisp. Hmm, what’s a better way of swapping ; and ::
And while it was true at the time that vim was purely synchronous, it’s not true anymore. Can’t really hold that against the author, of course, because he wrote it in 2015, but certainly can hold that against the person that posted an outdated article.
The Codebase
Really doesn’t matter to anyone that isn’t developing it, and Vim doesn’t really need a lot of new development in my opinion, so I don’t care how slow it is to develop. It has async. Its development resources are being wasted on crap like terminal support within vim, which is not the right way to use the terminal from vim (use ctrl-z [do some terminal stuff] fg) anyway, so getting useless features added faster doesn’t seem important.
In fact, out of all the developer communities I’ve encountered, Vim’s is the most hostile to change. Anything that isn’t a bug fix is frowned upon. Patches are often criticized for ridiculous reasons. After we posted our patch to the Vim-dev mailing list, the first reply was:
Most developers of free software don’t particularly like it when people turn up with big unannounced patches they want merged, with no previous history of contribution. I don’t know if the latter is true, but it probably is. It usually is. Who wants a bunch of code foisted upon them, in a different style from what they’re used to and what the project has, that they then have to maintain?
Does Neovim clean stuff up? Sure. But it cleans stuff up by removing support for the clipboard and incompletely reimplementing half of it.
NOTE: Don’t use ANSI style function declarations. A few people still have to use a compiler that doesn’t support it.
Regardless of whether this is a reasonable comment to make (and I personally think that without some evidence that it’s untrue, you shouldn’t really criticise it, as vim’s developers probably know its userbase better than you), I’m sure this has probably been mentioned elsewhere or should be obvious from the fact that that’s how the rest of the codebase does it! The number one rule of coding style is to maintain similarity with nearby code. If a codebase uses a particular style, even if it’s not the style you like, just go with it.
And for what it’s worth, often the pre-ANSI style function definitions are much nicer to read. float foo(x, y, z) float x, y, z; { ... } rather than float foo(float x, float y, float z) { ... } - why should you have to write float thrice?
The rest of that thread is me being as civil as possible, despite discouragement at every turn. The replies might as well be a paint-by-numbers guide on how to alienate new contributors.
What you call ‘async’ isn’t even proper async, it’s just ‘delay actually doing this action that still blocks the UI for an amount of time’. Could you in theory use that to implement something to poll an external process? Sure. Is that a good way to implement asynchronous communication with external processes in a text editor? I really don’t think so. That is brought up in the thread and then it looks like the person that posted the original patch basically never says anything in the rest of the thread.
Skimming the thread, it sounds like there were a lot of issues with the original patch, and they were pointed out, and you changed things in response to them. But you definitely can’t claim as you do in this article that you were strung along making changes then finally told it wouldn’t do. He said from the start that he was very retiscent about making those changes because they were error-prone and likely to cause lots of issues in the future. That’s pretty clear signalling that it’s unlikely that your changes will make it in.
Really doesn’t matter to anyone that isn’t developing it, and Vim doesn’t really need a lot of new development in my opinion, so I don’t care how slow it is to develop.
It’s funny when people admit this kind of stuff because it means (1) they haven’t (deeply) followed vim_dev for much time, and (2) their opinion doesn’t matter to anyone who actually isn’t happy with the status quo.
often the pre-ANSI style function definitions are much nicer to read
Vim switched to ANSI later, anyways. Bram very well knows the importance of keeping developers happy.
Personally, my main complaint about Vim’s development is that Bram doesn’t trust his own “core” developers (there are about two or three–or zero if you’re looking for anyone besides Bram with a deep understanding of the eval, input, or event-loop subsystems).
Things like nnoremap always deterred me from doing any serious vim configuration, and is in my eyes a quite good example for why I don’t like vim script.
From a programmers perspective, it’s at the very least confusing. What I read is “ rebind : to ; (or the other way around?), then do the same with they keys ; and :…” but wait, shouldn’t that make both keys do the same thing, since I just redefined : (or ;)? Or is this just some rerouting mechanism, a sort of compatibility layer between my vim and the real vim?
And as a frivolous emacs apologist, I’d like to give a practical example why I consider elisp to be better, while keeping in mind that I’m not remotly a elisp expert:
(defun swap-keys (kb1 kb2 &optional map)
"Swap the functions behind KB1 and KB2 in MAP"
(interactive "kFirst key: \nkSecond key: ")
(let* ((m (or map (current-global-map))
(f1 (lookup-key m kb1))
(f2 (lookup-key m kb2)))
(define-key m kb1 f2)
(define-key m kb2 f1)))
Now I have a function for swapping key bindings, which I think is useful if there is a real need to swap keybindings all the time. And not only can anyone with any lisp experience get what’s going on here, it’s also interactively usable via M-x swap-keys. When I include the time it took to find the function lookup-key and the interactive formatting, it all took me about 5 minutes. And again, I really don’t do much elisp, but IMO much more elegant.
(Your pervious example would then become
(swap-keys ":" ";" 'evil-normal-state-map))
All of the points made in the post mentioned are still true.
Neovim is still developed actively and the community is stronger than ever. You can see the latest releases with notes here: https://github.com/neovim/neovim/releases
Vim’s BDFL ultimately caved and released his own async feature that is incompatible with Neovim’s design that has been in use by various cross-compatible plugins for years (no actual reason was provided for choosing incompatibility despite much pleading from community members). Some terminal support has also been added to recent Vim. IMO both implementations are inferior to Neovim’s, but that doesn’t matter much for end-users.
There are still many additional features in Neovim that haven’t been begrudgingly ported to Vim.
At this point, I choose to use Neovim not because of the better codebase and modern features and saner defaults, but because of the difference in how the projects are maintained and directed.
Vim’s BDFL ultimately caved and released his own async feature
No, he didn’t. He didn’t cave. He was working on async, for a long time, with the goal of producing an async feature that actually fit in with the rest of Vim’s API and the rest of VimL, which he did. Did he probably work on it more and more quickly due to NeoVim? Sure. Did he only work on it because of pressure as you imply? No.
that is incompatible with Neovim’s design that has been in use by various cross-compatible plugins for years (no actual reason was provided for choosing incompatibility despite much pleading from community members).
NeoVim is incompatible with vim, not the other way around.
Some terminal support has also been added to recent Vim. IMO both implementations are inferior to Neovim’s, but that doesn’t matter much for end-users.
Async in vim fits in with the rest of vim much better than NeoVim’s async API would have fit in with vim.
There are still many additional features in Neovim that haven’t been begrudgingly ported to Vim.
The whole point of NeoVim is to remove features that they don’t personally use because they don’t think they’re important. There are a lot of Vim features not in NeoVim.
At this point, I choose to use Neovim not because of the better codebase and modern features and saner defaults, but because of the difference in how the projects are maintained and directed.
Vim is stable, reliable and backwards-compatible. I don’t fear that in the next release, a niche feature I use will be removed because ‘who uses that feature lolz?’, like I would with neovim.
No, he didn’t. He didn’t cave. He was working on async, for a long time, with the goal of producing an async feature that actually fit in with the rest of Vim’s API and the rest of VimL, which he did.
Where did you get this narrative from? The original post provides links to the discussions of Thiago’s and Geoff’s respective attempts at this. I don’t see what you described at all.
Can you link to any discussion about Bram working on async for a long time before?
NeoVim is incompatible with vim, not the other way around.
Huh? Vim didn’t have this feature at all, a bunch of plugins adopted Neovim’s design, Vim broke compatibility with those plugins by releasing an incompatible implementation of the same thing, forcing plugin maintainers to build separate compatibility pipelines for Vim. Some examples of this is fatih’s vim-go (some related tweets: https://twitter.com/fatih/status/793414447113048064) and Shougo’s plugins.
I get the whole “Vim was here first!” thing this is about the plugin ecosystem.
Async in vim fits in with the rest of vim much better than NeoVim’s async API would have fit in with vim.
The whole point of NeoVim is to remove features that they don’t personally use because they don’t think they’re important. There are a lot of Vim features not in NeoVim.
What are some examples of important features or features you care about that have been removed from Neovim?
The whole point of Neovim (according to the landing page itself: https://neovim.io/) is to migrate to modern tooling and features. The goal is to remain backwards-compatible with original vim.
Vim is stable, reliable and backwards-compatible. I don’t fear that in the next release, a niche feature I use will be removed because ‘who uses that feature lolz?’, like I would with neovim.
Do you actually believe this or are you being sarcastic to make a point? I honestly can’t relate to this.
The vim vs. neovim debate is often framed a bit in the style of Bram vs. Thiago, and the accusation against Thiago is typically that he was too impatient or should not have forked vim in the first place when Bram did not merge Thiago’s patches. I have the feeling that your argumentation falls into similar lines and I don’lt like to view this exclusively as Bram vs. Thiago, because I both value Bram’s and Thiago’s contributions to the open source domain, and I think so far vim has ultimatetively profitted from the forking.
I think there are two essential freedoms in open source,
the freedom of an open source maintainer not to accept / merge contribution,
in the very essence of open source, that users have the right to fork, when they feel that the maintainers are not accepting their contributions (preferably they try to make a contribution to the source project first).
Both of this happend when neovim was forked. There is no “offender” in any way. Thus, all questions on API compatibility following the split cannot be lead from the perspective of a renegade fork (nvim) and an authorative true editor (vim).
It was absolutely 100% justified of Thiago to fork vim when Bram wouldn’t merge his patches. What’s the point of open source software if you can’t do this?
I personally use neovim on my development machines, and vim on most of the servers I ssh into. The discrepancy for the casual usage is minimal, on my development machines I feel that neovim is a mature and very usable product that I can trust. For some reason, vim’s time-tested code-base with pre-ANSI style C headers and no unit tests is one I don’t put as much faith in, when it comes to introducing changes.
@shazow’s reasoning and this post are what I link people to in https://jacky.wtf/weblog/moving-to-neovim/. Like for a solid release pipeline and actual digestible explanations as to what’s happening with the project, NeoVim trumps Vim every time.
Typing brew install neovim reveals[1] why I don’t use it. At least, it’s what have made me stay away for now. I install Vim with Lua & Python which is already used by other apps, and does the job just fine. Not to say Neovim is any bad, I’ve just not seen the appeal just quite yet. Competition is always good :)
I prefer Vim’s approach of using JSON for communicating with external jobs instead of using Messagepack like Neovim does. I’m also not very partial about inventing a new binary format as a vimimfo replacement.
It is my understanding that Neovim wasn’t available on Windows for quite a while. I’m all for shedding features in order to facilitate building new ones, it might take Neovim in interesting new directions, but then the new project should not be considered a drop-in replacement for the old one.
(I even kind of like VimScript, despite its weirdness.)
viminfo is an ad-hoc unstructured format. shada is trivially parsable (and stream-able), because it’s just msgpack. It’s misleading to call it a “new binary format”, it’s just plain old msgpack with some sentinel values for guaranteed round-tripping to/from VimL.
It doesn’t make sense to prefer viminfo, which isn’t a format at all.
Anyone using OniVim among us? I’m wondering how does it compare to vim, Atom, VSCode and Sublime Text?
I’d much rather use vimscript than Python for scripting vim. Vimscript is no stranger a language than many other domain-specific languages out there. And I’d definitely rather configure using vimscript than Python or elisp. Hmm, what’s a better way of swapping
;and::And while it was true at the time that vim was purely synchronous, it’s not true anymore. Can’t really hold that against the author, of course, because he wrote it in 2015, but certainly can hold that against the person that posted an outdated article.
Really doesn’t matter to anyone that isn’t developing it, and Vim doesn’t really need a lot of new development in my opinion, so I don’t care how slow it is to develop. It has async. Its development resources are being wasted on crap like terminal support within vim, which is not the right way to use the terminal from vim (use
ctrl-z [do some terminal stuff] fg) anyway, so getting useless features added faster doesn’t seem important.Most developers of free software don’t particularly like it when people turn up with big unannounced patches they want merged, with no previous history of contribution. I don’t know if the latter is true, but it probably is. It usually is. Who wants a bunch of code foisted upon them, in a different style from what they’re used to and what the project has, that they then have to maintain?
Does Neovim clean stuff up? Sure. But it cleans stuff up by removing support for the clipboard and incompletely reimplementing half of it.
Regardless of whether this is a reasonable comment to make (and I personally think that without some evidence that it’s untrue, you shouldn’t really criticise it, as vim’s developers probably know its userbase better than you), I’m sure this has probably been mentioned elsewhere or should be obvious from the fact that that’s how the rest of the codebase does it! The number one rule of coding style is to maintain similarity with nearby code. If a codebase uses a particular style, even if it’s not the style you like, just go with it.
And for what it’s worth, often the pre-ANSI style function definitions are much nicer to read.
float foo(x, y, z) float x, y, z; { ... }rather thanfloat foo(float x, float y, float z) { ... }- why should you have to writefloatthrice?What you call ‘async’ isn’t even proper async, it’s just ‘delay actually doing this action that still blocks the UI for an amount of time’. Could you in theory use that to implement something to poll an external process? Sure. Is that a good way to implement asynchronous communication with external processes in a text editor? I really don’t think so. That is brought up in the thread and then it looks like the person that posted the original patch basically never says anything in the rest of the thread.
Skimming the thread, it sounds like there were a lot of issues with the original patch, and they were pointed out, and you changed things in response to them. But you definitely can’t claim as you do in this article that you were strung along making changes then finally told it wouldn’t do. He said from the start that he was very retiscent about making those changes because they were error-prone and likely to cause lots of issues in the future. That’s pretty clear signalling that it’s unlikely that your changes will make it in.
It’s funny when people admit this kind of stuff because it means (1) they haven’t (deeply) followed vim_dev for much time, and (2) their opinion doesn’t matter to anyone who actually isn’t happy with the status quo.
Vim switched to ANSI later, anyways. Bram very well knows the importance of keeping developers happy.
Personally, my main complaint about Vim’s development is that Bram doesn’t trust his own “core” developers (there are about two or three–or zero if you’re looking for anyone besides Bram with a deep understanding of the eval, input, or event-loop subsystems).
These points disagree with each other I feel.
Sounds like it “doesn’t matter” until it does. That is, when everybody else but Bram needs Bram out of the way.
Things like
nnoremapalways deterred me from doing any serious vim configuration, and is in my eyes a quite good example for why I don’t like vim script.From a programmers perspective, it’s at the very least confusing. What I read is “ rebind
:to;(or the other way around?), then do the same with they keys;and:…” but wait, shouldn’t that make both keys do the same thing, since I just redefined:(or;)? Or is this just some rerouting mechanism, a sort of compatibility layer between my vim and the real vim?And as a frivolous emacs apologist, I’d like to give a practical example why I consider elisp to be better, while keeping in mind that I’m not remotly a elisp expert:
Now I have a function for swapping key bindings, which I think is useful if there is a real need to swap keybindings all the time. And not only can anyone with any lisp experience get what’s going on here, it’s also interactively usable via
M-x swap-keys. When I include the time it took to find the functionlookup-keyand theinteractiveformatting, it all took me about 5 minutes. And again, I really don’t do much elisp, but IMO much more elegant.(Your pervious example would then become
(swap-keys ":" ";" 'evil-normal-state-map))I would love to have a feedback post, three years later. I don’t really know the status of Neovim right now
All of the points made in the post mentioned are still true.
Neovim is still developed actively and the community is stronger than ever. You can see the latest releases with notes here: https://github.com/neovim/neovim/releases
Vim’s BDFL ultimately caved and released his own async feature that is incompatible with Neovim’s design that has been in use by various cross-compatible plugins for years (no actual reason was provided for choosing incompatibility despite much pleading from community members). Some terminal support has also been added to recent Vim. IMO both implementations are inferior to Neovim’s, but that doesn’t matter much for end-users.
There are still many additional features in Neovim that haven’t been begrudgingly ported to Vim.
At this point, I choose to use Neovim not because of the better codebase and modern features and saner defaults, but because of the difference in how the projects are maintained and directed.
No, he didn’t. He didn’t cave. He was working on async, for a long time, with the goal of producing an async feature that actually fit in with the rest of Vim’s API and the rest of VimL, which he did. Did he probably work on it more and more quickly due to NeoVim? Sure. Did he only work on it because of pressure as you imply? No.
NeoVim is incompatible with vim, not the other way around.
Async in vim fits in with the rest of vim much better than NeoVim’s async API would have fit in with vim.
The whole point of NeoVim is to remove features that they don’t personally use because they don’t think they’re important. There are a lot of Vim features not in NeoVim.
Vim is stable, reliable and backwards-compatible. I don’t fear that in the next release, a niche feature I use will be removed because ‘who uses that feature lolz?’, like I would with neovim.
Where did you get this narrative from? The original post provides links to the discussions of Thiago’s and Geoff’s respective attempts at this. I don’t see what you described at all.
Can you link to any discussion about Bram working on async for a long time before?
Huh? Vim didn’t have this feature at all, a bunch of plugins adopted Neovim’s design, Vim broke compatibility with those plugins by releasing an incompatible implementation of the same thing, forcing plugin maintainers to build separate compatibility pipelines for Vim. Some examples of this is fatih’s vim-go (some related tweets: https://twitter.com/fatih/status/793414447113048064) and Shougo’s plugins.
I get the whole “Vim was here first!” thing this is about the plugin ecosystem.
How’s that?
Here is the discussion of the patch to add vim async from Bram, where he is rudely dismissive of Thiago’s plea for a compatible design (no technical reasons given): https://groups.google.com/forum/#!topic/vim_dev/_SbMTGshzVc/discussion
What are some examples of important features or features you care about that have been removed from Neovim?
The whole point of Neovim (according to the landing page itself: https://neovim.io/) is to migrate to modern tooling and features. The goal is to remain backwards-compatible with original vim.
Do you actually believe this or are you being sarcastic to make a point? I honestly can’t relate to this.
The vim vs. neovim debate is often framed a bit in the style of Bram vs. Thiago, and the accusation against Thiago is typically that he was too impatient or should not have forked vim in the first place when Bram did not merge Thiago’s patches. I have the feeling that your argumentation falls into similar lines and I don’lt like to view this exclusively as Bram vs. Thiago, because I both value Bram’s and Thiago’s contributions to the open source domain, and I think so far vim has ultimatetively profitted from the forking.
I think there are two essential freedoms in open source,
Both of this happend when neovim was forked. There is no “offender” in any way. Thus, all questions on API compatibility following the split cannot be lead from the perspective of a renegade fork (nvim) and an authorative true editor (vim).
It was absolutely 100% justified of Thiago to fork vim when Bram wouldn’t merge his patches. What’s the point of open source software if you can’t do this?
And as a follow up my more subjective view:
I personally use neovim on my development machines, and vim on most of the servers I ssh into. The discrepancy for the casual usage is minimal, on my development machines I feel that neovim is a mature and very usable product that I can trust. For some reason, vim’s time-tested code-base with pre-ANSI style C headers and no unit tests is one I don’t put as much faith in, when it comes to introducing changes.
Vim absolutely has unit tests.
@shazow’s reasoning and this post are what I link people to in https://jacky.wtf/weblog/moving-to-neovim/. Like for a solid release pipeline and actual digestible explanations as to what’s happening with the project, NeoVim trumps Vim every time.
Typing
brew install neovimreveals[1] why I don’t use it. At least, it’s what have made me stay away for now. I install Vim with Lua & Python which is already used by other apps, and does the job just fine. Not to say Neovim is any bad, I’ve just not seen the appeal just quite yet. Competition is always good :)[1]
But they need to stick to either nvim or neovim. This mixed naming is bad.
Neovim is the project name, nvim is the editor. Like “Mercurial” and “hg”.
Though I personally would like to move away from the name “Neovim”, it’s far too late.