Richard Stallman: What's magit? (2014-09)
The following post gives a description of the condition of GNU emacs development situation. It is, a sad condition, and was that way even in 2005.
[about vim/evil-mode/emacs]
This is at best an overly optimistic depiction of the state of things in Emacs land. As I am a former Vim user who switched to Emacs as well, I will counter this with a more realistic reply because the salespitch factoid on the “#emacs” channel on Freenode is there for a reason.
[Evil] ( https://bitbucket.org/lyro/evil/wiki/Home ) is pretty amazing. I'm not sure though where you've got the impression from that it is able of doing everything as Vim though. First, that's not even its goal, instead it goes for the far more interesting emulation of Vim's editing model and an extensible implementation. So no, no Vimscript execution, no full set of ex commands and most certainly no vimrc support. You will have to convert it yourself. This may be simple enough if all you did was flicking on sensible defaults, but if you were using non-trivial plugins, you'll need to learn Emacs Lisp first, then study the 20k SLOC of Evil because the documentation is mostly about customization, not extension. Another problem I've encountered is that keymaps are different in Emacs from Vim. Coming from Vim I did expect to have timers automatically set up for something like “jk to escape from insert mode” or usage of a key as both prefix and command. The former is badly solved in form of the [key-chord] ( http://www.emacswiki.org/emacs/key-chord.el ) (yes, it's hosted on a fucking wiki that can't even get the language for visitors right ( https://github.com/emacsmirror/emacswiki.org/issues/5#issuecomment-132888506 )) package which cannot even tell the order of the keys apart. The latter isn't even possible to do in Evil and just gives you a cryptic error message about a key sequence starting with a non-prefix key. And finally, the Vim idiom of remapping one key to a non-recursively applied series of keys is flat out impossible since Emacs isn't designed in terms of keys, but rather commands which you write yourself if something is lacking. Keyboard macros get you halfway there because they work recursively.
Emacs comes with interesting features, both for itself and its extension language. But just because the feature is there, it doesn't mean it is actually used... One of the more prominent examples is the execution of “asynchronous” processes to avoid blocking. Yet tasks as common as fetching and installing an Emacs package, grabbing mails with Gnus or just even using search and replace on a medium-sized document can stall the text editor for prolonged times and there are no easy fixes in sight.
[about GNU emacs development problem]
Being able to write Emacs Lisp is another great thing I couldn't live without. But since I'm still a mere human, I reuse other existing packages and almost immediately run into issues with them. It seems that the closer a package is to the Emacs core, the worse it gets. For example, something like Evil is surprisingly well engineered, something like linum however isn't. It was one of the very first things I've enabled as I did miss line numbers. Then I found out that not only it has an annoying display bug (as you scroll beyond shifts in orders of magnitude, the width of the line number strip changes) but an unbearable slowness that's stemming from it being implemented with overlays instead of being built into the display engine like with Vim. The only way of fixing this is going into the C sources and changing the data structures employed to go down from a complexity class of O(n2) to O(nlogn). You may guess what happened after a reasonable start of [an emacs-devel discussion] ( https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00616.html ). Spoiler: RMS vetoed it for no actual reason, something that has been observed [before] ( http://www.xemacs.org/About/XEmacsVsGNUemacs.html ) and [after] ( http://lists.gnu.org/archive/html/emacs-devel/2015-02/msg00360.html ). Given the amount of WTFs I've had when actually looking at the sources (which easily hold up with Vim's), I've started [a blog] ( http://emacshorrors.com ) about these.
Finally, regarding the community, RMS still being involved in the mailing list despite having passed on maintainership and repeatedly demonstrating [he has no clue at all] ( https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00583.html ) is the least of your problems. [There is a deeper going split] ( https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00526.html ) between the core developers and the rest of the community contributing to inofficial package archives [that easily outdo the official one] ( http://tracker.endlessparentheses.com/newPackagePlotEver.png ). [RMS most certainly is not amused] ( https://lists.gnu.org/archive/html/emacs-devel/2014-09/msg00627.html ). The switch to Git for version control was long overdue, but an arduous battle that has so far shown a handful of new contributors [what a hostile place the mailing list actually is
https://plus.google.com/+JorgenSch%C3%A4fer/posts/ZaZcunihGqc]. A fork would be an option, but I doubt it would succeed without people of the caliber of JWZ or the core developers because the vast majority of Emacs hackers only know Emacs Lisp, myself included.tl;dr: This is an overly rosy depiction of Emacs. While there's pretty amazing things, there are loads of deficiencies. Don't just switch text editors because someone told you so.
[posted by Vasilij Schneidermann (aka wasamasa). Source: [ https://www.reddit.com/r/vim/comments/3hs50h/i_heard_that_emacs_is_better_is_it_true/cuaf346 ] ]
wasamasa has 2 emacs blogs, they seem great:
wasamasa is recently () interviewed by sacha. Watch at http://www.youtube.com/embed/x1t9b7Fqo9c?rel=0
