I think that modality versus chording is a red herring. The real philosophical difference I see is whether the editor’s fundamental model is ‘things happen when you press keys’ (the key binding model) or if it has an actual grammar (the ‘composable operations’ model). An editor with a grammar for its operations is constrained in what it can do in a way that a key binding editor is not, but these constraints also give it power.
(‘Modal’ is also hard to really pin down. GNU Emacs is modal in several areas, for example, but the modes tend to be either shorter-term ones than vi’s or very large ones.)
think most people who have used both editors would agree that vim allows you to more efficiently edit text
I’d like to see a study, as I simply can’t agree with this.
I will agree that with a completely stock setup of both, vi(m) will win on the number of keys pressed, which I don’t feel is a very strong signal for overall editor efficiency.
–
Modal vs chording wasn’t the point, and isn’t the point. You can build modal editing on top of Emacs because at the end of the day, Emacs is a programming environment that is good for building editors.
Vim, on the other hand, is a great editor that has primitives for its language defined at a higher level of abstraction, making it harder and more awkward to build the same type of experience.
I believe the Acme developers did a test, though I don’t remember what editor they used. People using the keyboard claimed they were faster, but in reality, the mouse users (for selecting/moving cursor) were the ones ahead.
A little moot if the editor wasnt like vim no? But then this would be very hard to test, since vim proficiency takes a while to build, so you’ve got limitations to the kind of trials you can run.
I would recommend those people look into better implementations of a modal text editor like Neovim (vim forked toward Emacs,) Spacemacs (Emacs forked toward vim,) or Yi (completely new.)
Don’t forget Emacs with evil-mode, a vim emulation layer that achieves near perfect emulation!
[Comment removed by author]
I think that modality versus chording is a red herring. The real philosophical difference I see is whether the editor’s fundamental model is ‘things happen when you press keys’ (the key binding model) or if it has an actual grammar (the ‘composable operations’ model). An editor with a grammar for its operations is constrained in what it can do in a way that a key binding editor is not, but these constraints also give it power.
(‘Modal’ is also hard to really pin down. GNU Emacs is modal in several areas, for example, but the modes tend to be either shorter-term ones than vi’s or very large ones.)
I’d like to see a study, as I simply can’t agree with this.
I will agree that with a completely stock setup of both, vi(m) will win on the number of keys pressed, which I don’t feel is a very strong signal for overall editor efficiency.
–
Modal vs chording wasn’t the point, and isn’t the point. You can build modal editing on top of Emacs because at the end of the day, Emacs is a programming environment that is good for building editors.
Vim, on the other hand, is a great editor that has primitives for its language defined at a higher level of abstraction, making it harder and more awkward to build the same type of experience.
I believe the Acme developers did a test, though I don’t remember what editor they used. People using the keyboard claimed they were faster, but in reality, the mouse users (for selecting/moving cursor) were the ones ahead.
A little moot if the editor wasnt like vim no? But then this would be very hard to test, since vim proficiency takes a while to build, so you’ve got limitations to the kind of trials you can run.
I’m a vim user, but also not a fan of VimScript at all - it lacks the elegance of Emacs Lisp. Soon-to-be-released vim 8 does support async I/O:
Do you have any thoughts on Neovim?
Don’t forget Emacs with evil-mode, a vim emulation layer that achieves near perfect emulation!
it’s used in spacemacs (which started as a configuration package for evil-mode).