Total refactoring is not a solution. To Diego: Prove him wrong. I suspect that Bram has been maintaining the code base for so long, that he might need a bit more than a mere message to warm him up to the idea of a refactoring to the scale that you're undertaking. Also, you might not be the first person to contact him with such a proposal. I wonder how long it took for others before they gave up. Build something tangi…
Good points but I'm not convinced there exists a compelling reason to fork vim. From a user perspective there are no points of differentiation between NeoVim and vim. As an outsider looking in, it appears to me that NeoVim exists only to scratch the itch of some developers writing vim extensions. Is that reason enough to exist? Maybe. But what's the long-term aim here? Without a strong point of differentiation to att…
Bram Moolenaar responds to Neovim
121–130 of 151 posts
Re: Bram Moolenaar responds to Neovim
#122Perhaps this was mentioned the other day, but Neovim did make me think of this old chestnut from Joel Spolsky: http://www.joelonsoftware.com/articles/fog0000000069.html I realize Neovim is being characterized as an "aggressive refactor," but I'm sure that's the way Netscape thought of it as well. tl;dr Things you should never do: rewrite the code from scratch.
Re: Bram Moolenaar responds to Neovim
#123All Thiago got was: being ignored, one of the worst ways of disdain. Not just even a 'thanks but not interested'.
Other two guys who tried to provide patches to be merged on the same area also suffered from being mostly ignored (he replied to them but just once I think).
Re: Bram Moolenaar responds to Neovim
#124Re: Bram Moolenaar responds to Neovim
#125However, it's sure easier to refactor than start from scratch! At least LO has a working product. Best of luck to the Neovim guys :-)
Re: Bram Moolenaar responds to Neovim
#126Why aren't there other vim committers? Bram's conservatism makes perfect sense for someone who has to maintain this huge, consequential, intimidating codebase. Why hasn't he gotten some help?
Big old code bases, have a lot of what I call as 'tribal knowledge' associated with them. People go out, and do experiments only to burn their hands. Over years, the old maintainers generally accumulate a lot of ideas and 'tribal knowledge' to know why 'pie in the sky' ideas won't work. Nevertheless, people still try. A lot of them fail, a few succeed. The vim code base is around 300K lines of C code. I'm sure its no…
300K lines of code which does the actual work is simply too much code. And one should exercise great caution while dealing with it. Regression is just one thing, I'm sure there are a lot of places in the code which can silently break things you can't detect only to pop up in some strange case in the wild.
Re: Bram Moolenaar responds to Neovim
#127Or, at least, I think that's the best way to summarize the essential miscommunication between these two camps. Vim is, in the spirit of Unix, a single purpose tool: it edits text. Why would it need threading? async? background jobs? You can't type in two places at once, right?
NeoVim wants to be something like an IDE-lite. Text editing, yes, but with the ability to do background compilation/syntax checking, a bit of debugging here, some REPL-ish things there. For that you need a better async story, better process control, etc.
So, in the end, I don't actually see a problem here. Vim will cater to one audience, NeoVim to another. For my money (or donation to Uganda), I'm happy using tmux splits, sending text between vim windows and REPL windows, and keeping Vim primarily as a text editor with syntax highlighting. I would appreciate if some events could be backgrounded (e.g. syntax check on file save), but I don't think this needs a complete refactor.
Re: Bram Moolenaar responds to Neovim
#128Perhaps this was mentioned the other day, but Neovim did make me think of this old chestnut from Joel Spolsky: http://www.joelonsoftware.com/articles/fog0000000069.html I realize Neovim is being characterized as an "aggressive refactor," but I'm sure that's the way Netscape thought of it as well. tl;dr Things you should never do: rewrite the code from scratch.
With that thinking we never get Linux (NeoMinix), tmux (NeoScreen), Clang (NeoGCC), WebKit (NeoGecko), Subversion (NeoCVS), or Vim itself (NeoVi/Elvis/Stevie/etc).
Re: Bram Moolenaar responds to Neovim
#129Re: Bram Moolenaar responds to Neovim
#130Why aren't there other vim committers? Bram's conservatism makes perfect sense for someone who has to maintain this huge, consequential, intimidating codebase. Why hasn't he gotten some help?
Big old code bases, have a lot of what I call as 'tribal knowledge' associated with them. People go out, and do experiments only to burn their hands. Over years, the old maintainers generally accumulate a lot of ideas and 'tribal knowledge' to know why 'pie in the sky' ideas won't work. Nevertheless, people still try. A lot of them fail, a few succeed. The vim code base is around 300K lines of C code. I'm sure its no…
In a way, it's like a direct application of the style in /The C Programming Language/.