But here's the question: If Emacs defaulted to CUA, how many of those people would get to see Emacs's goodness? CUA alone doesn't get you there. To do most of the things that make Emacs stand out involves a fair amount of learning (and possibly customizing).
You have to put in some amount of effort before you get its benefits. While I certainly don't mind making simple things easier (e.g. CUA mode), I also see that doing so will not help new users much beyond doing very basic editing.[1] There are a fair number of stairs to climb to get to the point of being useful, and superficial stuff like CUA, etc simply eliminate perhaps 5% of the steps. Don't expect this change to make a big difference in retention.
As a corollary: If someone is not willing to learn how to enable CUA mode in the config file, then it is highly unlikely they will ever learn to use the features that make Emacs salient.
[1] I know, because my first decade of Emacs use was like this. I got past CUA mode, but otherwise used it for very basic editing. I always installed an IDE to do "real" work. It's only after one of my favorite IDEs died did I decide I really should just learn to use Emacs properly, and invested a week's worth of effort to be proficient in it. That week made all the difference.
> If someone is not willing to learn how to enable CUA mode in the config file, then it is highly unlikely they will ever learn to use the features that make Emacs salient.
I think that’s uncharitable. For a newbie low on confidence it’s often death by a thousand (paper) cuts: CUA mode, Surprising undo model, How to download packages, How do I enable fringes/margins, Windows-vs-frames, etc.
Each small change has a cognitive tax, and allowing users to feel psychologically comfortable and add tweaks slowly will make the learning curve much gentler.
I wouldn’t be surprised if the strongest indicator of whether someone sticks with Emacs is whether they have access to an Emacs expert with whom, or a community where, they feel comfortable being a newbie.
> I wouldn’t be surprised if the strongest indicator of whether someone sticks with Emacs is whether they have access to an Emacs expert
A lot of benefits of Emacs you get are when you realize you are operating a lisp VM. Enabling all the same things that other editors do in the same way will not suddenly make them choose Emacs. Someone needs to nudge them towards the good parts of emacs/show a powerful application that will make them use it.
I tend to get surprised by this complaint - especially in the article where undo-tree was recommended as an alternative.
Both the Emacs undo and undo-tree are "surprising" models in that very few standard editors support anything beyond the most basics. Personally, I've not had trouble with Emacs's undo (beyond it not visualizing it). Switching to undo-tree may be OK, but it's still surprising. Switching to the standard one in most editors is a pretty serious regression.
> How to download packages
Once I properly learned Emacs, I did not have a need to do this for the first few years. I'm not referring to decades ago, but the 2010's. While I agree that a convenient way to download things from MELPA would be nice, I hardly see not having it as a barrier. Most people new to, say, Visual Studio don't start with "How do I download plugins". And once you know some of Emacs basics, package downloading is but 2-3 lines in the config file and a keybinding that presents you a menu.
> How do I enable fringes/margins
Again, I don't see this as a beginner feature. I don't know how to do this, and I've never wondered about it - both as a beginner and as an advanced user. I've use Visual Studio quite a bit and never tried to enable/disable them there either. I don't think this is something a typical beginner would deal with.
> Windows-vs-frames
What is the issue beyond terminology? It wouldn't bother me if we rename these. I don't see a great enhancement, though.
> Each small change has a cognitive tax, and allowing users to feel psychologically comfortable and add tweaks slowly will make the learning curve much gentler.
Although I personally don't recommend it, but have you heard of Customize in Emacs? It used to be (and may still be) the recommended way to change config options. It has help on various options, and is an interface - not "edit config file with Elisp commands". Many users say it really helped them and certainly flattened the learning curve.
> I wouldn’t be surprised if the strongest indicator of whether someone sticks with Emacs is whether they have access to an Emacs expert with whom, or a community where, they feel comfortable being a newbie.
I did not have access to an expert. I simply read a book on it[1], and the rest was from occasional Google searches. In those days there really wasn't that much friendly info online, but it was enough to maintain the momentum. There is a ton more stuff these days to help beginners. Not to mention Youtube videos.
(BTW, as a reference point, I was a power Emacs user for almost a decade before I learned enough Emacs Lisp to write a simple loop - too many people have the misconception that one needs to know elisp to use Emacs well).
As someone commented on HN in an earlier submission: Who becomes a power user of anything without reading manuals? That it's not straightforward to do simple text editing in Emacs is a fair criticism[2], but also a bit of a shallow one. There are plenty of friendly text editors for simple text editing. Let people use them! The value proposition of Emacs is in its powerful capabilities, not basic text editing. It's a bit like complaining that Ferraris are a pain to learn to use when all you will do with it is grocery shopping. Just use a regular car!
[1] This was the norm in the pre-Internet days (80's and 90's), BTW. Even in the 00's when interfaces were nicer, the people I knew who were power Visual Studio users became so by reading books or online manuals - not by random discovery or random Internet pages.
[2] It's ironic that I write this, given that the only reason I began using Emacs is that the other option people led me to (vi) was even harder to do basic text editing. At least with Emacs, I could type and it behaved like most editors I'd been accustomed to in DOS. With vi I was immediately confronted with command/insert dichotomy, not being able to edit prior to the insertion point, etc.
It's also amusing that people complain about Emacs not being like "normal" editors, and folks invoke Stack Overflow polls to indicate its lack of popularity, and yet vim is used by a quarter of SO users and is ranked 5th. vim is also beginner hostile, so the beginner hostility really isn't the reason for Emacs's low usage.
I don’t wish to do a point-by-point rebuttal as you’re entitled to your view — just that it misses the perspective of a large fraction users. As for me, I’m fairly happy using Emacs Doom.
> While I agree that a convenient way to download things from MELPA would be nice, I hardly see not having it as a barrier. Most people new to, say, Visual Studio don't start with "How do I download plugins".
I think this statement is untethered from reality, and matches approximately zero people I know. Almost everyone using a text editor is using it for purposes which would definitely be helped by task-specific enhancements (plugins which are typically much easier to get in other editors/IDEs)
> I did not have access to an expert. I simply read a book on it [...] given that the only reason I began using Emacs is that the other option people led me to (vi) was even harder to do basic text editing.
Yes, and the fact of the matter is that today people have many editor options which are very powerful and also have a much friendlier learning curve.
> I think this statement is untethered from reality, and matches approximately zero people I know.
Note that I'm referring to Visual Studio, not VS Code.
In my last job, we didn't use any plugins with Visual Studio for a bunch of years before one developer convinced the rest to use Resharper.
> Almost everyone using a text editor is using it for purposes which would definitely be helped by task-specific enhancements (plugins which are typically much easier to get in other editors/IDEs)
I find this statement untethered from reality. I think this gets to the crux of much of this discussion. There seems to be an implicit assumption that Emacs exist for writing code (hence the comparisons with VS Code, etc).
I think if you poll most Emacs users, while programming will definitely have more weight, a lot of people use Emacs for all kinds of things unrelated to programming: TODO management, document authoring, writing emails, etc. Most of my Emacs usage in my first job was simply editing text files, not programming. This is in line with most non-SW engineering jobs: They need text editors, but not plugins. Over 95% of my home usage is non-programming related.
So when you imply almost everyone using a text editor is using it for purposes where they will want to look for plugins, that's simply far from the truth. Until recently, most people who used text editors used Notepad (the default Windows one), and I've never managed to convince a Notepad user to use anything more powerful. Nice plugins would not sway them.
While Emacs is heavily used by some programmers, I do not think it is the aim of Emacs. It is a general purpose text editor, and a platform for writing text oriented apps.
One small comment, many users do get plugins almost immediately.
If you load a (for example) Java file, a little popup appears saying "Hey, do you want me to download the default Java plugin". Now I can imagine Emacs would find it incredibly hard to pick a "default" plugin to offer users, but it is super helpful to get started.
> Although I personally don't recommend it, but have you heard of Customize in Emacs?
I have, I've tried it, and it's terrible compared to virtually any other editor's equivalent for editing preferences/settings. It's super hard to navigate and search, it's difficult to figure out the terminology if you don't already know it, it's unclear how various settings affect one another, and IIRC it can actually make changes to your configuration file that conflict with editing it in any other way. To be fair, I am not a regular Emacs user, but getting sucked into the insanely frustrating tar pit of Customize made Emacs seem far more inscrutable to me for years.
If I could suggest just one change to make Emacs feel more "modern," it would be to entirely redo the Customize section to make it behave more like VS Code's preference system: one single page with collapsible headings, clear descriptions, and perhaps a super-top-level "behavior" control that makes batch changes to make Emacs more comfortable for users coming from different editors (e.g., choosing between a Canonical Emacs mode, Vim mode, or CUA mode). It doesn't have to try to cover every possible setting -- just hit the top several dozen and then say "for everything else, there's Lisp".
> Vim is also beginner hostile, so the beginner hostility really isn't the reason for Emacs's low usage.
This strikes me as half-correct, as someone who's made serious attempts with both of these editors. They're both difficult for beginners to get used to, but once you get over the initial learning hump, Vim was always much easier for me to tweak and configure. That may sound nuts, but editing .vimrc feels like editing an INI file, and at least in my experience, Vim's plugins are much better behaved when it comes to not stomping on one another. Every attempt I've made at getting serious with Emacs has ended in spending hours trying to get two or three extensions I want to use to play nicely with each other; with Vim (or VS Code), this almost never happens.
I've long suspected Emacs's greatest strength is also its greatest liability: you can do almost anything with it if you learn Emacs Lisp, but it often feels like you must learn Emacs Lisp to do almost anything with it.
> Most people new to, say, Visual Studio don't start with "How do I download plugins".
Not to pile on with the other reply, but, well: editors like Visual Studio Code, Atom, Panic's new Mac-only editor Nova, and even Sublime Text to a degree actually make plugins front and center. It's a very different approach than what Emacs and Vim have historically taken, but I think it's contributed greatly to their mindshare. VS Code in particular goes out of its way to recommend plugins to you based on the files that you've recently edited.
> If I could suggest just one change to make Emacs feel more "modern," it would be to entirely redo the Customize section to make it behave more like VS Code's preference system
It's probably not hard for someone to do that with Emacs - all the bits and pieces are there. I wouldn't be opposed to this.
> They're both difficult for beginners to get used to, but once you get over the initial learning hump, Vim was always much easier for me to tweak and configure.
At the risk of starting a pointless war, I suspect it may be because Vim just has an order of magnitude fewer features than Emacs does. Many people have wanted Org mode in Vim, and no one has been able to make a good one.
> when it comes to not stomping on one another. Every attempt I've made at getting serious with Emacs has ended in spending hours trying to get two or three extensions I want to use to play nicely with each other
I believe you because this complaint does come up from time to time. I must have been simply lucky that this has been a very rare problem for me. In fact, I often tell people Emacs is great because one can take disparate packages and use them together to get powerful features. To me it exemplifies the UNIX philosophy of combining tools better than most UNIX utilities themselves do. The worst I've encountered is a conflicting keybinding.
> you can do almost anything with it if you learn Emacs Lisp, but it often feels like you must learn Emacs Lisp to do almost anything with it.
I view that as one of the biggest myths. I was a power user for about a decade before I learned to even write a loop in Emacs lisp. The most I knew was setting the value of variables. That's enough to be a power user.
Now that I know Emacs lisp, I don't have a burst of productivity compared to when I was ignorant. I've customized to solve a few annoying problems, but I've not had any moments of "Oh man, I wish I knew how to do this all these years."
I don't encourage Emacs users to learn elisp. If I ranked things they should explore in Emacs, there would be a lot of stuff higher on that list than learning elisp (org-mode, etc).
I'm not actually sure Vim has an order of magnitude fewer features than Emacs at this point. I've made recent attempts to make good friends with both Vim and Emacs, and have experience with Emacs 27 and Vim 8. In my hopefully not too cynical observation, Vim fans tend to overestimate Emacs's complexity and capacity to be confusing (even saying this as someone who has admitted to being confused by Emacs!), while Emacs fans tend to underestimate modern Vim's capability.
I am not sure whether I just have bad luck with Emacs extensions. :) I suspect it depends on what languages you're delving into; I found trying to get HTML, CSS, PHP and JavaScript modes all playing nicely together (literally, since the same file could technically have all four, with a secondary template language thrown in for good measure!) challenging. But that particular adventure was a while ago. (My most recent attempt was with Spacemacs, which, uh, I'll just say it has some great color schemes.)
Re: Emacs Lisp: well, I did say "often feels like," not "actually is." :) I'm sure you're right; it's just that sense that a lot of early problems get solved by "to do the thing you want to do, paste this code into your init file," and getting past the feeling that you're assembling a configuration you don't reallllllly understand -- and thus may not be able to debug if something goes wrong -- can be a hurdle.
> while Emacs fans tend to underestimate modern Vim's capability.
I don't doubt vim is very powerful for things like programming, but can I use it to automatically scan my emails for keywords and make TODOs out of them (in just a few lines of code)? Can I use vim to compute derivatives of math functions and automatically insert them into LaTeX documents? And so on.
Don't look at Emacs merely as a programming editor. It's a playground for anything textual.
I don't understand why Emacs needs customisation to be useful. If it's not useful without customisation, why not ship a default 'customisation' that makes it at least somewhat useful to start with.
You have to put in some amount of effort before you get its benefits. While I certainly don't mind making simple things easier (e.g. CUA mode), I also see that doing so will not help new users much beyond doing very basic editing.[1] There are a fair number of stairs to climb to get to the point of being useful, and superficial stuff like CUA, etc simply eliminate perhaps 5% of the steps. Don't expect this change to make a big difference in retention.
As a corollary: If someone is not willing to learn how to enable CUA mode in the config file, then it is highly unlikely they will ever learn to use the features that make Emacs salient.
[1] I know, because my first decade of Emacs use was like this. I got past CUA mode, but otherwise used it for very basic editing. I always installed an IDE to do "real" work. It's only after one of my favorite IDEs died did I decide I really should just learn to use Emacs properly, and invested a week's worth of effort to be proficient in it. That week made all the difference.