How Emacs should get more users
A response to Making Emacs popular again.
This assumes that is a worthy goal, which I believe it is. I won't be discussing whether or not we should do it, I'm only presenting how I think we should do it.
First, realize that users are different
- Some like to click around most of the time, and only use the keyboard to directly enter text
- People are very opinionated about keybinds. Non-hacker types just want common user access, and anything else is a non-starter. Most people don't want to learn and change! :(
- Some hate the mouse, and don't actually have that many options to avoid the mouse in modern applications
- Some never customize anything
- Some care about how their interface looks. I'm one of these, because I believe that if I have to stare at a thing for a large part of my life, it should look aesthetically pleasing, and be an environment I want to be in
Recognize why the competition is succeeding
- VSCode's, and (to a lesser extent) Sublime's Package managers are trivial to use and have thriving contributions. I think Emacs is very hurt by the default repository being relatively empty compared to MELPA, and getting MELPA working is difficult (especially on Windows). Contributing to the repositories is hard (maybe some barrier is okay)
- Fundamental keys are preserved across all editors (C-c, C-v, C-s, C-o, C-z, C-f being the most important)
- Their UIs look slick (especially Sublime's)
Sublime innovations which are here to stay
Sublime Text specifically has influenced all modern editors, as far as I can tell. Here are the things I think they caused to happen, and critical features they popularized:
- C-p quick jump to file in project folder or open buffer
- C-S-p run command
- Multiple cursors are more easy to understand and faster to use than macros. The
multiple-cursors
Emacs package is quite good, but needs better clipboard support (which I address below) - Out-of-the-box Goto definition (both under cursor and goto any symbol in project) automatically works
- Dark theme by default
- Minimal and slick interface. VSCode is less slick, but very much more slick than Visual Studio proper
I don't think VSCode is sufficiently innovative over Sublime Text, but is still a useful data point.
Red herrings
The following are Emacs Improvement ideas that I think are red herrings, and may even reduce the quality of Emacs:
- Language server. It's difficult to setup on Windows, doesn't work for any projects not using one of the popular build systems (e.g. CMake), is damn slow (for a test, try Sublime Goto any symbol in project vs. VSCode, and be astounded by how much slower LSP-based solutions are), and in my opinion is not necessary given the added complexity
- Moving to any web-technology for internals. Sublime was very strong with just Python as a customization language, and a native (closed source!) backend. Javascript should not become the biggest language! Electron is resource hungry and complicated
- Moving away from ELisp. With improved documentation, it won't be hard to learn for anyone competant enough to be writing editor modifications
- Moving away from C. At the end of the day, only the most aware power users will care about the underlying implementation, as long as it is reasonably fast and uses resources responsibly. Emacs' relatively new
native-comp
branch will hopefully bring Emacs in its current state much closer to those goals - Trying to sell Emacs as something it is not. It will always be the most powerful editor, and never be Notepad, and we should lean into that
- Pushing Emacs' keybinds. Users need to see the fun stuff first, then transition into more efficient keybinds
What I think makes Emacs shine
In a few words, comparatively low effort, more powerful customization. No editor lets you make the perfect environment like Emacs does.
Here are things I think are NOT important about Emacs, and therefore we should not be resistant to change:
- Default keybindings. Keybindings are easy to change in almost any program. Vim people, people with alternate keyboard layouts, people with alternate keyboards (I personally use the Kinesis Advantage2, which e.g. removes the need for home-row motion keys) all require different binds. Start with something familiar to them and let them change them to fit their needs
- The current mouse UI (toolbar etc). We should look at how VSCode and Sublime do their UIs instead of following the old style
Things I am opinionated on, that I think Emacs should lean into
These aren't necessarily the best things to do to increase userbase, but are things I don't want to see go away.
- No tabs. Being able to have hundreds of files open without caring is a very nice thing. The Sublime-style C-P to jump to buffer by name should be the preferred way (I use
ido
for this, but IMO it should be a builtin feature with default binds, at least in the user mode for People used to Windows/CUA apps, which I will talk about later) - Remaining text-based. I don't use the mouse for anything in Emacs, so I'm definitely too biased to be reasonable here. I think C-S-p Run command (M-x in Emacs) should be the main way people find new commands, though good documentation in a tree for all commands would be good for discovery
- Being able to create a minimal UI. Right now, Emacs' non-text-based UI is pretty ugly compared to modern editors. Unless we can prove we can make a modern, "pretty" one, we shouldn't make it a requirement to have the ugly one
- Never requiring project files. I hate making project files. Multiple branches, myriad third-party Git repos, cross-project dependencies, etc. all make project files a huge pain to create. Emacs doesn't care about projects, and shouldn't.
Projectile
context-awareness is convenient however (it mimics Sublime same-folder C-p quick open) - File opening experience. I love
find-file
and loathe Windows File Explorer. It should be an option, but I would hopefind-file
would be recognized as superior by most users. Especially with ido suggesting files and fuzzy search, it's unbeatable
What I think should be done
These things would, in my opinion, make Emacs attract and keep more users. They are ordered roughly from most to least important
User keybind profiles
At startup, offer categories (starter packs, a bit like suggested in the mailing list) for the most common user groups:
- People used to Windows/CUA applications
- People who like Vim-style editing
- People already familiar with Emacs (the smallest group, by far!)
It should just be a dropdown/radial list selection, not any sort of advanced configuration UI or language they need to use.
Additionally, the profile should change the following behaviors:
Clipboard
The Windows/CUA application profile should be based as closely as possible to VSCode and Sublime Text, which have quite similar bindings to each other. Importantly, the Windows/CUA profile should have a truly equal clipboard experience. What I mean by that is:
- C-c, C-x, and C-v for cut, copy, and paste
- Cut and copy go straight to the system clipboard as well, and paste will pull from the system clipboard when necessary (see
simpleclip
) - No fancy multiple kill or anything. At the most, have multiple-cursor clipboard support like sublime, where if you do a multi-copy in Emacs and paste in another application, you'll get the complete contents of your multi-copy, with newlines
- Marking text does not copy it to the clipboard
Window docking/splitting
With the keybinds close to Windows/CUA/Sublime, and the clipboard as identical in behavior as possible, the only big things remaining are buffer management and window management. These will need to be learned by the user unless Emacs chose to adopt a tabbed interface with docking and splitting.
If we do want mouse-controllable docking and splitting, it should in my opinion be based on Visual Studio proper. dear imgui
docking
branch uses a similar model, and it works very well. A minimal mouse-based solution could be like Blender, where when you drag a corner widget it splits the window, then merges if you drag a view until it's very small. I don't actually think Sublime nor VSCode excel at window splitting/merging, so we could beat them in that aspect if we wanted.
I personally don't think that is necessary because I'm happy with just keyboard commands. I base my config on browser shortcuts: C-t splits (a new "tab"), C-w closes buffer, C-S-w closes window (remove split), C-S-t reopens buffer.
I think not having tabs is nice because I don't have to muck with tab order, or having so many tabs that you have to scroll and read tiny clips of text. A ido-style selection list is sufficient in my opinion. Clicking on the buffer's name should trigger that selection list.
Tutorial
Rather than a text-heavy tutorial or splash-screen, start with a very minimal centered text saying most fundamental commands:
- How to find commands
- How to open a file
- How to get help
- How to change settings
This is much like Sublime and VSCode's empty window, while still leaving space for the splashscreen info.
For example, the splashscreen would present the Emacs logo and the following text (where keybinds are automatically adjusted to the user's profile, in this case the Sublime and VSCode-like CUA profile):
C-S-p : find and run command
C-o : open a file
C-h : get help
C-h-m : list available keybinds
C-p customize : change settings
C-S-p quit-window : quit emacs
Key: C- = hold Ctrl key and press...
S- = hold Shift key and press...
M- = hold Alt key and press...
That very short key is necessary and efficient at introducing the user to Emacs' non-standard keybinding format.
It may be necessary to include buttons for all of those commands adjacent to the keybind.
Then, with a significant amount of whitespace below that, the normal splashscreen text and info.
As for the tutorial, there should be a high-level version created that only introduces the fundamental Emacs concepts, as briefly as possible, e.g.:
- Buffers are open files or views
- Each buffer has a mode, which determines the keybinds, highlighting, and behavior of Emacs
- Customization happens via
customize
dialog, and almost everything about Emacs can be changed via ELisp
I don't think new users should start with the Emacs binds, which means the regular C-h t
tutorial should be changed for those users to not have any of the key motion distractions.
ELisp Introduction
For more intermediate/advanced programmers, a "Intro to ELisp" tutorial should be written, which should contain the following info:
- How to create an ELisp file that is auto-loaded at startup (e.g.
.emacs
) - How to learn which functions are relevant to potential modification (using
C-h m
to find the mode's functions,C-h f
to describe and go to the definition of functions) - Setting values
- Creating interactive functions (and binding to them)
- Doing conditional operations
- Doing simple list operations: creating a list, checking if it contains something, adding things, iterating
It should be as brief as possible - an overview. I find the current documentation to be a bit too all-inclusive to serve as a very good introduction.
I don't think ELisp is significantly worse than e.g. Python or Javascript, but its ramp-up documentation certainly is (or at the very least, there are much fewer people trying to introduce ELisp than e.g. Python or JS).
Discovery
I think Ido-everywhere and smex
present a good way to make Emacs more discoverable. They resemble Sublime's and VSCode's selection dialog, used for selecting themes, projects, buffers, project files, goto-symbol, etc.
I also think fuzzy search is a very powerful addition to searching. Most post-Sublime editors I have tried have fuzzy search and Sublime Goto/Command functionality.
Package visibility
Potentially on the splashscreen, show a list of the most popular packages. This helps people who need e.g. Web-mode
to immediately see that Emacs does cater to their needs, they just need to install that package first.
Preferably, MELPA should be effortless to enable (e.g. a checkbox that says "see packages from other sources").
Appearance
Start by default with a dark theme. All modern code editors do this. Offer to change themes on the startup screen.
Because the Icons/mouse-driven UI is rough, have an option to disable that as well. When clicked, print that they can find commands via M-x (preferably saying "Alt-X", or for Windows keybinds profile, C-p).
Emacs should ship with a modern-looking font (possibly many). My personal choice is Ubuntu Mono, but licensing certainly wouldn't be possible for it. If a modern looking and licensable font does not exist yet, potentially using the default "best" font likely to be on that user's OS may be a good idea:
- Consolas for Windows
- Ubuntu Mono for Ubuntu
- Whatever code font e.g. XCode uses on Mac (I'm not familiar with Macs)
Adding some padding to the margins and additional line height also goes a long way to making Emacs look more modern.
Present Emacs as an editor for the True Power User
This helps lean into its obscurity as a sign that only the experts are wise enough to use it, and if you put in the effort to try, you too can be come a master. I think a lot of people are attracted to Vim because of this, whereas Emacs misses that audience.
I think Vim's learning curve is much sharper keybinds-wise, but surprisingly still has a larger userbase. We should look into why that is the case. Vim's configuration language and extensibility is god-awful, so I don't think Emacs' use of ELisp is actually the problem there.
In conclusion
I think none of my proposal would be impossible, nor even very difficult to implement.
I understand it's mostly a political problem. I think getting buy-in is made much easier by having the user profile selection on the splashscreen, such that power emacs users can get the same experience they expect by clicking two buttons (click dropdown, select "Classic Emacs", or just run a command, etc.).
The profiles proposal means that the new changes could be completely isolated from the classic experience to not alienate any existing user. I do think that the default should be the new experience, however. New users might not want to change any settings until they've experienced the program, so the default should be the most familiar compared to other text editing experiences.
Other comments
My opinion on Doom, Spacemacs, etc.
These are harmful to Emacs and users of Emacs for two reasons:
- They fragment the user- and developer-base
- They increase the layers of abstraction between the user and their environment. Emacs shines because you can easily change anything. Having to wade through an extra config you don't understand is not helping
We can kill these by making base Emacs the most popular and accessible distribution.
My config
My config is much like the Windows/CUA/Sublime profile I proposed, with the expected clipboard and multiple-cursors behavior.
I get along just fine using ETags/CTags and xref for a LSP-mode type experience. I found setting up LSP stuff to be very annoying, and the user experience terribly slow on a 4 million line codebase.
Some of the X-factors I've gotten that I wouldn't get easily from non-Emacs editors:
- Using
compile
to run all sorts of useful things - One-button builds with
compile
that conditionally kill processes to be rebuilt, then conditionally execute them. Afterwards, get rid of build output buffer if it succeeded via a hook (I hate unused windows staying open; it will remain in buffers, just no longer be visible) - Granular project management: I can switch which project I want to build without having to save a new project file, change which buffer I'm in, reload Emacs, etc. - just change an Elisp variable via a function using
ido-completing-read
and hit compile - Easily implemented my own search window: I can put my cursor on a term, then decide whether I want to search the internet, use
codesearch
, useag
,codesearch
with a specific index file, etc. with only 2 keypresses
These things took time and effort, but it was rewarding to make and would have been impossible to get out of the box. My requirements are too specific to fit in other editors, which is why Emacs is still the best.
Responses
I linked to this article on reddit, which spawned some lively discussion. My opinions on LSP and Doom/Spacemacs proved to be controversial. They may have poisioned the well for the rest of my ideas here for some people, unfortunately.
If I were to write it again I would leave out the Doom/Spacemacs section, especially because it was added as an afterthought anyways.