It needs to be more novice-friendly, having pre-CUA [1] shortcuts and terms ("windows" & "frames") is a trivial but powerful obstacle, I think. It needs to modernize its extension language: I still can't believe a 'then' clause needs a 'progn' if it's to contain multiple statements, but 'else' doesn't. I'm crossing my fingers for Guile, which, though still a niche language (Scheme), is at least more modern and standardized. I don't know how robust the interaction between the elisp (which is, like it or not, is here to stay) and Guile code is.
Emacs has a humongous codebase at over 2M lines of code [2] (of which, admittedly, 1.5M of that is elisp), with some deep black art as legacy from what it needed to run on when it started (thanks to ESR's work, the git history actually spans the entire 30 year history of the project! Here's the very first commit: [3] [Though admittedly because of RCS's per-file semantics, the early history is a bit weird).
But more importantly, it needs more mindshare. I'm hoping the git transition can help that.
[1] http://en.wikipedia.org/wiki/IBM_Common_User_Access [2] https://www.openhub.net/p/emacs (slow server) [3] http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=ce5584...
With VIM or Emacs I have no idea where to start, except for maybe a few weeks in the terminal and manual before I can even start to code. Then it is still an open question about what it will scale to. I am not sure I want my environment to look like [this].(http://blog.jetbrains.com/pycharm/files/2013/06/vim3-1024x74...)
With Spyder, RStudio and Octave GUI I can start programming right away, I can see the benefit of the IDE right away, the only problem is I have 3 different text editors with their own short cuts and features.
> (for basic open/navigate/edit/save/search/replace) functionality in a few hours
Do you know how long it takes in Sublime / Atom / TextMate ? Approximately zero.
I use Spacemacs (Emacs with VIM inside) and even after months of working with it I'm still faster in Atom. That's not because I'm "doing it wrong".
Spacemacs fixes some of that integration. cmd-X C V S all work. but no cmd-F or cmd-R
and cmd-f is not the same as ctrl-f. in the emacs tongue it is referred to as s-f
predating is irrelevant. most of the younguns using text editors were born well after emacs was created.
Emacs is technically capable of being customized to suit established usage patterns. its only cultural stubborness that stops it.
I will admit that the vi learning curve can be stupidly steep in places, but right down at the novice end it's not bad at all.
From my angle, I've been learning/using the CUA-type keyboard shortcuts since I was about 8 years old - so that's 20 years now, and 16 or so before I wrote a line of code.
The question is not 'how quickly can I learn open/save/etc in vim/Emacs?', or even 'how quickly can I learn open/save/etc and remember it next time I open vim/Emacs?' but 'how quickly will I be more productive in either of them than something that does use all the shortcuts I've been using for two decades and are basically wired into my unconscious as deep as the need for oxygen, food and sex?'
On that scale, I think a few weeks is the most generous estimate possible. I understand why people love vim and Emacs, but they often underestimate how steep the learning curve is if you're very, very used to doing the same things slightly differently.
I can't immediately find the survey that struck me, but here's a Quora answer [1] that cites O'Reilley selling twice as many Vim books than Emacs, the Debian PopCon results [2] that are rather striking (but Debian PopCon has quite the preselection bias, and the data may not cover all sub-packages properly), and Ubuntu's results [3] are a bit harder to parse but also striking, with vim-common at 2714181 / 25488 installs / "votes" (regular uses), vs emacsen-common (the highest-placed "emacs" package) at 330647 / 1669.
[1] http://www.quora.com/Are-there-more-Emacs-or-Vim-users [2] https://qa.debian.org/popcon-graph.php?packages=vim%2C+emacs... [3] http://popcon.ubuntu.com/by_inst
C-h (+ k or m) is probably one of the first key chords you are to learn when starting emacs, from there everything is downhill.
People use what's available, having Vim preinstalled is a powerful headstart.
There are people who can program very productively in vi (I'm not one of them), so they can use vi for long and short tasks. I can program very productively in emacs but I don't consider it the right tool for quick one-off edits of something. Also vi comes with pretty much every UNIX-like base system I know of, while emacs is often off in a port system somewhere.
Using emacs in daemon mode with launchctl on osx and then making a shell alias and an automator launcher for emacsclient that just connects makes starting the new client so fast that I can use emacs for the quick jobs, too. The only thing I have to do now is get used to the emacs command equivalents for the quick edit jobs. For example, in vim I can open a file to a specific line, delete that line and then the first 5 characters of the next 50 lines, and exit the editor in just a few keystrokes, while in emacs I'd still be playing with C-h a and googling. The things I've spent the most time in emacs doing, common lisp, clojure, latex, and so on, have a very different set of common operations than the common sysadmin tasks I used vim for.
I don't particularly enjoy programming in vi, but I tend to do it quite a bit when making small changes to our codebase on my dev box in the sky and I don't want to deal with the overhead of starting an IDE locally.
It also stopped people from laughing at me when I ran nano. :p
Here are the results from the latest SO developer survey. The data may be biased, but it looks like vim outnumbers emacs by 5:1: http://stackoverflow.com/research/developer-survey-2015#tech...
Here's me complaining about slow text rendering: http://www.reddit.com/r/emacs/comments/2e8byy/slowass_text_r...
Still, I keep using emacs because so far nothing else I've tried touches it. But I dream of an editor with the flexibility of emacs, but a strong focus on speed and correctness. (And terminal support -- terminals are very much still with us!)
A tall order, I know :)
My problem with extensible editors is that you have a combinatorial explosion of possible configurations, which therefore aren't fully tested. So you always end up with something slightly buggy.