“Matt and I worked for months to add asynchronous functionality to Vim. From that experience, I have few good things to say about Vim’s dev community”.
I read that exchange on the mailing list and Matt and him were unreasonable not the vim community, They added friction to their patch not being submitted. Their patch was poorly conceived, didn’t think about the user, caused a segfault and lockup. Bram’s criticism was that he didn’t want it merged until he was convinced that it worked and addressed several concerns. And we was right, it didn’t work and didn’t address many concerns.
Each response from them was “We don’t want input, there is too much input, we just want this patch merged”.
As a vim user, If this has any reflection on the NeoVim developers, I am not excited.
Remember the Atom editor? How it was an uber editor for developers, but was terrible as an actual text editor? I would prefer a solid text editor over “clean code”.
If the only good thing about vim is the user interface, why not try Emacs with evil-mode? I made the switch recently and I’m enjoying it: the vim bindings are very, very complete, and you have an incredibly scriptable environment to work in.
I’ve been considering making this switch for a while now, but the main thing stopping me has been the fact that while evil-mode might duplicate the vim interface, it won’t duplicate all my vim plugins (I use a handful of custom text objects and ‘verbs’ quite often). So I’m really excited about the idea of a better vim that still has plugin compatibility.
Do you need your vim plugins as they are? Considering the number of Emacs packages, you could probably find something that provides more-or-less the same functionality. As for custom text objects, I have seen a couple in the MELPA package archive, and if those don’t do, you could embark in an Elisp hacking adventure.
This is true. In fact, it might be easier to write these plugins for evil-mode than it was for the original authors to write them in vimscript, depending on how evil-mode plugins work. On the other hand, it’s always going to be easier for me to just do nothing, and having to find or reimplement plugins doesn’t help me overcome my inertia. Still, it might happen one day, but I think the prospect of neovim is only increasing my vim inertia.
“Matt and I worked for months to add asynchronous functionality to Vim. From that experience, I have few good things to say about Vim’s dev community”.
I read that exchange on the mailing list and Matt and him were unreasonable not the vim community, They added friction to their patch not being submitted. Their patch was poorly conceived, didn’t think about the user, caused a segfault and lockup. Bram’s criticism was that he didn’t want it merged until he was convinced that it worked and addressed several concerns. And we was right, it didn’t work and didn’t address many concerns.
Each response from them was “We don’t want input, there is too much input, we just want this patch merged”. As a vim user, If this has any reflection on the NeoVim developers, I am not excited.
Remember the Atom editor? How it was an uber editor for developers, but was terrible as an actual text editor? I would prefer a solid text editor over “clean code”.
If the only good thing about vim is the user interface, why not try Emacs with evil-mode? I made the switch recently and I’m enjoying it: the vim bindings are very, very complete, and you have an incredibly scriptable environment to work in.
I’ve been considering making this switch for a while now, but the main thing stopping me has been the fact that while evil-mode might duplicate the vim interface, it won’t duplicate all my vim plugins (I use a handful of custom text objects and ‘verbs’ quite often). So I’m really excited about the idea of a better vim that still has plugin compatibility.
Yeah, that’s a good point — I agree that neovim is really exciting.
(of course, the best solution to your problem would be to write a vimscript interpreter in elisp, no? :p )
Do you need your vim plugins as they are? Considering the number of Emacs packages, you could probably find something that provides more-or-less the same functionality. As for custom text objects, I have seen a couple in the MELPA package archive, and if those don’t do, you could embark in an Elisp hacking adventure.
This is true. In fact, it might be easier to write these plugins for evil-mode than it was for the original authors to write them in vimscript, depending on how evil-mode plugins work. On the other hand, it’s always going to be easier for me to just do nothing, and having to find or reimplement plugins doesn’t help me overcome my inertia. Still, it might happen one day, but I think the prospect of neovim is only increasing my vim inertia.