I disagree that Emacs doesn't start at the level of composability; it just has very different expectations of its users. Emacs "big idea" is the programmability of the environment, therefore, its composability is at the level of lisp functions. The very best Emacs users take advantage of composability at this level through keyboard macros, evaluating expressions, and building new commands.
Vi took to the unix philosophy: it's all here and can be composed as you need. Even with Vim's extensibility, it hasn't gotten close to Emacs at the functional level of composability.
Sublime, et al, took as Emacs "big idea" the same thing the author did, "you can create commands", but that is too narrow of a view, and that's why those editors haven't displaced Emacs.
On that topic, Emacs is also a multi-mode editor. There is editing mode, which most people are familiar with, and there is programming mode, where one makes the editor more able to handle the problems one is facing. Until one masters programming mode, Emacs will just seem to be the "editor with cumbersome key mappings".
You don't get Vim. Its composability is at the user interface level, not at the extensibility level. It's a different editor, tough to learn but incredible when you pass a certain threshold.
I've used emacs for about a decade, and Vim for about another. I switched to Vim for practical reasons but place both editors at equivalent levels of quality. Both are great. Not perfect, but great. The article is spot on at identifying the core lessons in each.
I'm not really commenting on vim. I actually had a previous comment written where I said almost exactly what you said. I'm not even saying one is better than the other, just that the author's understanding of Emacs was, IMO, less than complete.
The funny thing is both vim and Emacs have these weird learning curves: Emacs starts easier (you can actually type something; wtf is a mode?!), then vim becomes easier (modes and command composing over finger gymnastics and pages-long key bindings), then (and this is, of course, my opinion) Emacs with its programmable everything starts to shine. I wonder how much of the editor wars are simply where people are along that continuum.
Agreed evil in emacs is very good. It is the best vim emulator I've ever used and is even better than vim in instances (like when it shows you everything you are replacing as you type the replace command).
Lately though, after near a decade of using vim, I've been trying to unlearn vim. Many editors provide easy ways to navigate, search and replace the way you do in vim 80% of the time without all the baggage that modes bring. The baggage that vim creates is muscle memory training to navigate with hjkl which is incompatible with non-vim input boxes. I'm also not a fan of the vim source code or its creator and it may be too late for me to care about neovim.
Another negative aspect of vim is that at least in myself and maybe in others it leads to an unearned increase level of engineering confidence as you master an arguably useless, esoteric skillset that doesn't translate into better understanding of basic computer science topics. Vim does help improve regular expression familiarity, but that may be it.
I wasn't much a fan last time I tried it. If you know more than the very basic vim movements, you'll find they start conflicting with the emacs keybindings; and it's frustrating to remember which one does which.
In emacs i just gave up and tried to learn vanilla emacs even though i am a vim user.
That's precisely the parent's point. The Vim model (I'll exclude vi from the discussion since it lacks core aspects of Vim's composability like text objects, and almost no one should be using it) is about having a largely inflexible editing language built off of composability. The Emacs model is built around infinite extensibility instead. That's why implementing Emacs in Vim would be fundamentally at odds with the principle of Vim, but it's very possible to implement the Vim model in Emacs, and Evil does a nice job.
Well, there's vimacs (http://www.vim.org/scripts/script.php?script_id=300) which gives you the basic keybindings and modeless editing. I agree though that the vi modes for emacs give you more than the emacs mode for vi.
I started out in Emacs, used it and customized it for years. Then I decided to see what I was missing in Vim, so I switched entirely for two years. I became very comfortable with that world.
Then I spent about a year in the strange netherworld of viper-mode and vimacs, switching around more or less at random.
Eventually, I landed back in plain emacs for most things and have been there for the last ten years. I have nothing against vim and still use it from time to time, particularly when I'm working on a remote server. I just realized that for me, emacs was at least as capable on every front and seemed to suit my way of working better.
I’ll bring out the one of the more influential articles on Vim to further explain the author’s point—Your problem with Vim is that you don't grok vi: https://gist.github.com/nifl/1178878
Vi took to the unix philosophy: it's all here and can be composed as you need. Even with Vim's extensibility, it hasn't gotten close to Emacs at the functional level of composability.
Sublime, et al, took as Emacs "big idea" the same thing the author did, "you can create commands", but that is too narrow of a view, and that's why those editors haven't displaced Emacs.
On that topic, Emacs is also a multi-mode editor. There is editing mode, which most people are familiar with, and there is programming mode, where one makes the editor more able to handle the problems one is facing. Until one masters programming mode, Emacs will just seem to be the "editor with cumbersome key mappings".