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