It's over 40 years old but it has fewer and fewer users younger than that. VS code is rapidly taking over it's niche and without modernization, of many kinds, emacs will die out in a generation.
I have used emacs since I was an undergrad, 25+ years ago and I have no plans to switch. That does not stop me from recognizing the fact that VS Code does almost everything that emacs does, often better, has orders of magnitude more users, is much more approachable and is being improved at a much faster rate. As they say, "this time its different".
This kind of ties back in to the point of the article.
For people who have used $EDITOR for 20+ years there's little incentive to change to something else, but if you want to bring in fresh eyes to your project so that there'll be enough people around in another 20 years to maintain the whole thing it behoves you to think about attracting those people.
Sane defaults and being more approachable is a good way to do that.
That is the splash page that hasn't changed much since 2000. Reading the helpfully highlighted first menu entry do you think that Emacs has a tutorial?
Users who can't even be bothered to read the text in front of them are not an asset to a project that doesn't charge them, they are a liability since they force the project in stupid directions. The death of firefox is a perfect example.
The thing that Emacs should focus on the future is true concurrency. Nice to haves would be a non-gtk gui, adding scheme scripting support and releasing a space cadet mechanical keyboard.
I don't follow this stuff closely, but I do have it in my RSS reader.
Here's someone recreating the Space Cadet keyboard key caps -- i.e. the plastic covers for the keys, not the actual keyboard. This is a more modern profile (key shape), rectangular/cylindrical similar to modern keyboards rather than the spherical top of the key like in the 1970s and 1980s.
It might give you an idea how expensive a custom keyboard would be.
I've been using Emacs for an entire 1 year and I have to say - I only like OrgMode. I've barely tried out Magit, so maybe that's another killer feature. But for programming, I think that Emacs is too steep a hill to climb when VSCode and JetBrains' IDEs offer so much out of the box or just a few clicks/commands away. In Emacs, you can can, in theory, do anything you like. And it is so impressive when you customize it to behave in a certain way. It's also more open for tweaking than any other editor. 'describe-function' and 'describe-key' are super cool, for example. But VSCode is just more practical. Instead of writing some Elisp (which is an incredibly awkward language) to customize your IDE, you can just go to the extensions screen and very likely find and download an extension that does what you want. Maybe not exactly. Maybe you could make Emacs behave much more precisely, according to your preferences. But you might spend hours, if not days, depending on your level of expertise. Meanwhile, with VSCode, you essentially bypass all that.
You are totally right. Being an emacs user for 10 years, I suggest vscode when people ask what editor to choose.
While preconfigured Spacemacs, Doom and others are doing a good job in turning emacs into OOB editor, they still require some tinkering with lisp, while in vscode you just install plugins and you are done.
Have you tried preconfigured Emacs distributions, like Doom or Spacemacs? You just open your init.el file and uncomment packages you want to enable with pretty good defaults. They have package managers preinstalled too, like straight.el. Also, every package has easy to paste initialization snippet
It helps to have a lot of very visible brackets when people sign up, it scares away the majority who won't cut it.
Emacs is in that unfortunate position that you can learn the shortcuts and 'use' it for months before you even see your first bracket and end up thinking the brackets are the problem, not you.
The number of times I've heard people demand the scripting language change to python...
For comparison of numbers and growth rate: VS Code was new in April 2015, had a claimed 2.6 Million active monthly users in Nov 2017[1], became the most popular editor in StackOverflow's user survey in 2018[2] with 34% of respondants and again in 2019 with 50% of respondants, to a claimed 11 million users in 2020[3]. Its codebase has been forked 16,000 times[4].
In 5 years, VS Code has gained more users than the population of Switzerland, than the population of London, than Uber has drivers. I'm not suggesting Emacs ought to chase maximum popularity, but if there was any feeling that "the editor / IDE market was saturated" or "there was no demand for editors", that doesn't seem accurate.
I think adopting cua-mode as the default would go a long way towards reducing the initial friction for new users.
Most of the time when I try to get people to adopt emacs, they abandon it because it feels like a huge task to relearn basic text manipulation. They never get to actually see what makes emacs good because they don't feel compelled to get past the initial bump.
Have you tried with a init.el with cua-mode to see how people adopt it? My intuition is incentivizing on org-mode or magit has higher chance of adoption than cua-mode. After all an alternative free editor(VSCode/notepad) is probably good enough for their current usage.
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.
The article on lwn pretty much nails it. The discoverability of features would be great. I have been used emacs for ~20 years and I had finally switched to VSCode after I was stuck for half an hour finding a way to type single-quote in org-mode. I had found a way first time in the past, but then I completely forgot how to do it and was forced to search again. (It something to do with locales, it is traditional for Russian to use < > and << >> quotes instead of ' and ", so someone made it default when LANG=ru_RU.UTF8, so one types ' but gets < or >. But how it was done? How to undo this damage to emacs? Now I cannot remember it one more time, but luckily I do not use emacs now so it doesn't matter anymore).
I don't want to see any changes. There's nothing in emacs that requires any modifications or "modernization" from my perspective. But I'm nearly 57, which is why emacs, like me, will (mostly) die out.
In a generation, vim and emacs will still be around with their minuscule but loyal user bases of tinkerers and VS code will have long been replaced by something newer and flashier.
Ah, but you miss its hackability aspect by virtue of being a lisp runtime. I wouldn't say eclipse is anywhere close to "hackable" as emacs is.
Just run C-x b <scratch> RET and you have an elisp buffer to manipulate the state of the entire editor. It allows for superfast iteration, compared to the plugin development cycle of other editors. Though, vscode/javascript has definitely made it much closer to what is possible in emacs.
"Superior" for sure isn't the word I'd use, almost every one of the editors and IDEs make a bunch of trade-offs that appeal to different audiences
IMHO, the barrier to entry for modification for both emacs and vim is much lower than their competition: evaluate text in a buffer, observe change to your editor
I don't know of any other tooling has that immediate feedback loop remeniscient of the old JS in HTML (or the dev tools console, as apples to apples) approachability
I am more accustomed to vim than emacs.
Some things I painfully miss when using something else than vim : quick and easy shortcuts to jump around the file, delete words/blocks/parenthesis, place marks to jump between parts of one or multiple files, macros, filtering parts of the file through external command...
