Why not to use Emacs

Why not to use Emacs   emacs

I've talked at extreme length on this page about the reasons why I like GNU Emacs, even to the point of defending certain aspects of it that are usually treated as sub optimal even by extremely dedicated users and maintainers of the software. However, I am no fanatic. Emacs has flaws, some of which I think can be overcome, and some of which I think are the inherent consequence of the tradeoffs it needs to make to be the unique thing that it is.

In fact, there's a reason I phrased the first section on this page so neutrally, as just being about what's unique about Emacs, not "why you should use Emacs" or "why Emacs is the best text editor/OS." And the reason for that is simple: I think the things that make it unique can be massive strengths for some people and complete deal breaking downsides for others. This is why recommending Emacs is one of those things you should really only do to someone who is actively looking for a change, or maybe already a little interested in it (perhaps from looking over your shoulder while you use it). It's like a religion that way: the best way to convert people isn't overt evangelism, but just by not trying to convert them or caring about converting them at all, – only living your life and showing the attractiveness of what you're doing, and letting people who are already interested or looking for a change ask you of their own accord what's up and how they can get in on it. Of course, just like a religion, adherents can often fail at this through enthusiasm to share something that has changed their lives 😉

So, the downsides of Emacs.

  1. Surmountable but still very real issues:

    1. Asynchronous programming has not sufficiently permeated the Emacs ecosystem, and most examples of asynchrony/multiprocessing currently in the ecosystem rely on non-Emacs external tools, which, while advantageous, in my opinion, in the name of reusing work and deep host OS integration, means that you often have to install or have a package download and compile a myriad of little external utilities to use a package that won't occasionally lock up your editor. This can be fixed with my multiprocessing suggestions.
    2. Emacs Lisp, while not a bad language at all in my opinion, is somewhat old-fashioned, and moreover has an issue with a proliferation of different alternative standard libraries. This can be at least improved with my suggestions for improving Emacs Lisp.
    3. Emacs Lisp is relatively slow, which is a problem for something that's essentially running an entire editor and suite of applications in a single thread (we'll get to threading later). This is being improved about 3x with native compilation, and will probably be further improved (possibly up to a further 10x) if Guile Emacs ever happens.
    4. Emacs's defaults are really often just completely baffling and counterproductive (some examples: the way it handles backup and autosave files, the default completing-read system, the fact that GCMH isn't the default GC strategy, the way canceling an empty interactive search reverts to batch-mode search, the fact that which-key has only recently been added and is off by default, the default JIT lock settings, and much more). Even if respecting IBM CUA isn't really in the cards, there are an infinite number of other things that could be done to make the initial experience of the editor so much better, so many built in packages that could help contribute to a better out of the box experience that just come turned off or misconfigured by default. This could be fixed if only the mailing list politics would allow it.
    5. The Emacs garbage collector is a stop-the-world, non-incremental, non-copying, conservative, single-threaded, low-throughput, non-memory-returning toy compared to modern garbage collector technology. This is being fixed with the scratch/igc branch, which is very likely going to be merged into master.
    6. Interfacing with external programs that speak JSON or JSON-RPC like LSPs can cause the single Emacs thread to choke on large projects just from having to ingest that amount of serialized data. This is being fixed by the new JSON parser.

  2. The insurmountable problems that you simply just have to accept if you want to use Emacs:

    1. It will always be slow-er than something like Helix or NeoVim, because it fundamentally relies on a things like late binding for every possible function, hooks and advice, most of the editor being written in a highly dynamic scripting language, and just doing more in the editor.
    2. It will always be possible to freeze or substantially slow down the editor's response times if you or the authors of the packages you use aren't careful, siduce threading into Emacs without destroying what it is at its corewithout destroying what it is at its core (barring some miracle solution I can't see).
    3. Thanks to its malleability and transparency, it will always be easier to break your Emacs or get strange, inexplicable behavior with it, than any other editor. This isn't as bad as the similar situation with Linux distributions because the core, clean image is always there, an emacs -Q away, but it's still an issue.
    4. If you want to have full control and configuration of your editor, you're going to want to jump into the deep end with vanilla Emacs, but that will always require more configuration and (unfortunately) maintenance than a "just works" editor like VSCode or Helix. Of course, this is very robustly and completely obviated by things like DOOM Emacs, but if you're getting into Emacs, that might not be what you want.

    5. Emacs being a whole separate computing environment on top of your existing operating system:

      • will not be able to perfectly integrate and align with the rest of your OS, which you will almost certainly have to interface with in the form of applications that can't be embedded into Emacs and your window manager, within which it exists, unless you use EXWM;
      • is also simply… another computing environment: if you like the one you already have well enough and don't want any of the additional benefits Emacs can offer then, well, I can't blame you. Although I know I prefer Emacs.

Emacs truly isn't for everyone. If the unique properties of Emacs seem more important to you than their concomitant downsides, then welcome to the club; if they don't, no hard feelings – it's certainly reasonable to have genuinely different priorities!