Category: Emacs

Emacs satisfies all of the preconditions for a retrocomputing hobby:

1. Long (fourty years), interesting, storied history and set of precursors
2. Maintains many aspects of its heritage, connecting you directly to that heritage (for instance, Emacs Lisp is a clone of MACLISP, the original Lisp Machine language, that exists nowhere else today)
3. A vibrant and passionate community regularly making things for/with it just for the fun of it, often some of it actually art (and a long history of that being done, given point one).
4. It can be completely understood inside and out, up and down, left and right, and modified.
5. It has a lot of unique properties compared to modern computing systems, deeply influenced by its history.

It also has many neat advantages over other forms of the hobby. Namely:

1. It can be very productively, justifiably, and usefully put to work in your everyday life
2. A lot of the things that you do with it as a hobby can end up benefitting your everyday life and work productivity
3. It's completely free!

This makes it the ultimate retrocomputing hobby!

Some of the most important meanings that you can imbue into text, in my opinion, are:

1. Symbols to label the intended "thing" that region of text is supposed to represent
2. Data structures representing the structured concrete syntax tree of the annotated text, to easily maintain an identity between the two and retrieve it
3. Context or related pieces of data, whether textual or structured
4. Hypertext links

For a concrete example of the first, the package Marginalia looks for any lines annotated with the file symbol in the minibuffer, and uses those lines as paths to look up file information, which it then adds as further metadata to those lines. This means that anything that provides completions in the minibuffer, independent of Marginalia knowing about the specifics of that code, or that code even needing to know about Marginalia directly, can add useful metadata about the files it is offering to the user to choose from just by encoding the semantics of the text lines it is presenting as suggestions to the user, like so:

(completing-read-default "Note file: "
                         (let ((files (directory-files-recursively quake-org-home-directory ".*.org")))
                             (lambda (str pred flag)
                                 (pcase flag
                                     ('metadata `(metadata (category . file)))
                                     (_ (all-completions str files pred))))))

Imbuing meaning, especially in the form of hypertext links, is a common pattern in Emacs, from grep-mode to compilation-mode but for a powerful example of the benefit of the latter three points, just look at org-mode, which is able to take plain text and give it all of these extremely highly structured and interactive and automated, almost GUI or structural editing style features for manipulation, while maintaining an identity between what the program is seeing and doing, and plain text notation that can fully allow it to recreate all of the information necessary to manipulate and understand the document, is the fact that org mode is able to maintain a full parse tree of the document with references to certain positions in the text, but also annotate the text itself with references to that parse tree, thus meaning there's two way communication – when the user inspects or edits some part of the plain text, it's easy to get the structural and semantic meaning of that part of the text and manipulate it for them to produce new text.

There's also things like the incredible Hyperbole and Embark packages, which have the ability to read and use text already imbued with meaning, but also use plain-text patterns to imbue text that wasn't intentionally imbued with meaning with new meaning, bringing this whole concept full circle and making the entire Emacs environment just that much more powerful.

It seems to be common wisdom in the Emacs community that Emacs Lisp is just this terrible programming language that everyone hates, on the level with something like PHP. However, I just don't think that's the case. Emacs Lisp is strongly typed, has an extremely complete and extensive standard library, it has all of the power of a full Lisp including live mutation of a running system, procedural macros, symbolic programming, and homoiconicity, a copy of the Common Lisp standard library (including Common Lisp generic multimethods), and an implementation of Common Lisp's incredibly powerful object system. Yes it's a Lisp-2, but so is Common Lisp, and I personally think that's an inconvenience, but not a fatal flaw.

Honestly, in my opinion, it has both fewer gotchas and is simpler, more straightforward, and more pleasant to program in than many popular modern languages, including things like JavaScript and Python. Python is chockablock full of shittily implemented (the fact that match ing on a variable can assign it, even if it already has a value, or that default argument values are effectively singletons, or any number of other things) and non-composable features (lambdas can't have multiple lines, anyone?). Or what about the insanity that is JavaScript? Even Lua has its share of truly awful design decisions (such as the fact that "arrays" are just tables with consecutive integer keys, so if you accidentally introduce a non-consecutive key into the middle of the consecutive keys of an "array", the iteration primitives will assume that's the end of the array and stop there).

Moreover, Emacs Lisp has a lot of things built into it that make it much more suited to something like Emacs than the alternatives:

• Things it gets from being a Lisp that other languages lack:

  Macros

  Macros are an extremely important facility to have for something like Emacs, where you want a powerful, general facility for package authors to create domain-specific languages for less-technical users to create the functionality they want (see things like Transient or Easy Menu or Use Package or Hydra, or the macros provided in the Emacs Lisp standard library like with-eval-after-load or with-current-buffer or with-temp-buffer), and want a language that aligns with the Emacs philosophy of being flexible and extensible and programmable itself. Yes, you can do some degree of domain-specific-language creation in other languages, but it's usually done with a bunch of language constructs that essentially take the powerful generality of macros and break them up into separate features, bastardize them, and sprinkle them around the language, and such domain specific languages are usually quite weird, brittle, and composed of lots of little tricks to get them working. Ruby is not an acceptable Lisp just because it has some nice syntax for things.

  Runtime Dynamicism

  the ability to redefine a function, method, or data type, or evaluate an expression, within the context of a running process, and have the whole thing change immediately, without built system hot reloading tricks or incremental compilation or anything of the sort is crucial for something like Emacs.

  Regular Syntax

  Emacs has structural editing commands built into its core. The syntax that gives those structural editing commands the most powerful functionality with the least parser complexity is Lisp, or something similar, hands down.

  Homoiconicity

  The ability to represent actual, executable code, in a format that can be meaningfully structurally manipulated, walked, and modified – that is, linked lists of symbols – as well as just evaluated, as opposed to just as raw strings you have to munge into the right shape and then pray work when you evaluate them, is crucial to functionality like the unity of user interface and programming paradigm. For instance, the ability to capture the actual resultant code the user executes (impossible if you have no representation of code as data) and use it in a data structure that the user can easily view and edit, and then ask Emacs to programmatically manipulate to produce a reusable command that's just like every other function or command reliably, is key to having keyboard macros as powerful as Emacs does. Without such homoiconicity, user actions would have to be represented as new, custom data structures that are then interpreted to be run later by code written in the language the system is actually written in: a mini sub-language that creates distance between the user and the internals.

• Things that it has uniquely:

  Advice

  Having the ability to advise the behavior of any function in the language at a native level, instead of having to declare advisable functions in a special way or something, as you'd have to do in any language where this was not built into the ground level, is extremely important. See the section on composable modifications.

  Buffers

  Having the concept of buffers built into the language virtual machine, instead of implemented as a library, ensures that buffer manipulation is literally as fast as it can get; moreover it makes it easier for buffer manipulation to form the core language primitive for text manipulation, which benefits user-system homoiconicity and also performance at text manipulation, since buffers are backed by a special data structure designed for fast text manipulation that's much faster than the regular strings other languages use (in this case, gap buffers, but as far as Emacs Lisp is concerned, that's just an implementation detail).

  Buffer-Local Variables

  The ability for some global state variables in Emacs Lisp to be transparently buffer-local (as in, can map to different values depending on which buffer the current code is executing in) is crucial for encapsulation, composability, and generality of Emacs modes and functionality, and it would be almost impossible to achieve ergonomically without that concept being built into the language – which in turn requires buffers themselves to be built into the language.

  Propertized Strings

  The fact that the native, first-class, default string data type in Emacs Lisp is propertized text is deeply important to it being able to ergonomically integrate with Emacs's fundamental paradigm. No other language has this.

  Dynamic Scope

  being able to temporarily redefine a variable or function just for the tree of function calls below a scope is incredibly useful for flexibility, customization, and malleability. Pure lexical scope is simply too brittle by itself!

  Simplicity

  Despite being quite powerful – honestly a good step above most modern scripting languages in power, despite being "merely a domain-specific language", a fact which is what enables such incredible applications to be regularly written in the Emacs computing environment – Emacs Lisp is at its core a very simple and consistent language. I think this is important for learnability.

Now, is this to say that Emacs Lisp can't be improved, or that it's the best language ever? Dear god no, far from it!

1. Its standard library, while incredibly complete and featureful for the purpose, is full of the same inconsistent naming and argument ordering as Common Lisp's. I think a major naming and argument ordering overhaul could be very helpful to avoid common mistakes (although I don't see how this could happen).

2. Without cl-lib and eieio, Emacs Lisp's standard library, while rich in other ways, lacks crucial functionality for things such as list manipulation, loop comprehension, conditionals, an object system, and generic multimethods; thus the attempt to discourage the use of those already built in and quite performant libraries out of a dislike for Common Lisp idioms (and concerns over "bloat" which somehow didn't apply to the creation of a second duplicate standard library with seq.el) has led to a proliferation of alternative standard libraries, or at least components of such, such as dash.el and seq.el, which are:

   1. in the former's case, not built in, which leads to larger startup times and slower execution due to dependency bloat all for functions which duplicate functionality already available within Emacs,
   2. in both cases less in line with the Emacs Lisp programming style historically, based on what's been around longer, what has been used the most, and Emacs Lisp's shared heritage with Common Lisp, and
   3. at least in the latter's case, much slower¹.

   I think switching to encouraging a more Common Lisp style of programming, including making copious use of cl-lib would solve this problem (the opposite of Stallman's suggestions, ironically, because I don't think the "simpler" and "more elegant" libraries like seq.el provide complete enough functionality in the way the Common Lisp extensions do, so it'd just lead to a further proliferation of libraries).

3. And of course there's the lamentable fact that Emacs Lisp is a Lisp-2 – I think the weight of the technical arguments falls strongly in favor of Lisp-1s; however, it's far too late to change this aspect of Emacs Lisp, and it's also far from the disaster many think it is.
4. It's also pretty slow, even with native compilation (although not slower than Python!), which is obviously a problem when you're writing tens of thousands, hundreds of thousands or even millions of lines of complex code in it.

In all, however, I think these issues must be fixed without replacing, removing, superseding, significantly changing, or deprecating Emacs Lisp. Both because of the unique features of Emacs Lisp listed above, and because one of the biggest strengths of Emacs is the 40 years of package development that has occurred for it, all of which was done in Emacs Lisp and depends on that language intimately. Losing incredible, killer packages like paredit, smartparens, org-mode, org-roam, magit, elfeed, SLIME, CIDER, web-mode, AuCTeX, Emacs Speaks Statistics, emacspeak, mu4e, Proof General, citar, and the many other killer applications that have been created for Emacs that regularly convert users of other editors and attract laypeople, would be a complete and utter disaster. The existence of these packages is part of the core appeal of GNU Emacs, what makes it worth engaging with in the first place!

I also think that trying to introduce other languages – even equally domain-specific ones – alongside Emacs Lisp would be a mistake, since it would ruin many of the important properties I've been talking about above, such as the total homogeneity of the Emacs computing environment.

What I want is not the replacement or elimination of Emacs Lisp, nor a rewrite of the Emacs core into Rust, Common Lisp, or RnRS Scheme, then – what I want is the evolution of Emacs Lisp towards a sort of Common Lisp sibling language that is slightly simpler and has Emacs extensions, and then the gradual assimilation of the core into Emacs Lisp as it grows faster. Emacs should be Emacs Lisp. What I want least of all is for Emacs to become a polyglot environment, where impedance mismatches make inspecting, debugging, integrating, interoperating, and dynamically modifying various packages difficult, and where I have to learn a new language for every package I might want to contribute to.

In light of all this, I think the new Guile Emacs has the right idea in this regard: replace the engine under Emacs Lisp with something better – allowing better performance and more expressiveness, and homogeneous interface with similar Lisp languages – while keeping Emacs Lisp the same, but opening the door toward evolution down the road. I also think that the Emacs maintainers have been making solid strides toward this already with the introduction of lexical scoping by default, cl-lib itself, native compilation, and probably in Emacs 31, MPS!

Also, on a personal note, I not only think the "nicer language du jour" – Python, JavaScript, Scheme, or Lua – can't do the job as well as Emacs Lisp does, I also just like them a lot less than basically any Lisp. And I just find Emacs Lisp a complete and utter joy to use, despite its warts, in a way I don't enjoy those languages.

See also: UNIX, Lisp Machines, Emacs, and the Four User Freedoms.

Each of the main tenets of the UNIX philosophy has essentially a kernel of truth to it:

• we want to break functionality down into individual pieces so that they can be handly used as tools,
• we want a common data interchange format so that everything is interoperable,
• and we want to make sure to design everything to be composable.

However, it misunderstands how best to achieve each and every one of these options. Human-readable text is a good medium for data, but it is too flexible to be the data interchange format, by itself, and lacks out-of-band capabilities, as I've said before. Breaking down functionality into entirely separate programs/processes is way, way too hard of a line, causing both severe overhead (forking is expensive), making it more difficult and slower to communicate data in a useful way (no shared memory space), and turning each set of functionality into a tiny little black box where it's difficult to modify or adapt its behavior except through a million esoteric and idiosyncratic flags (see also: programmability vs customizability). Likewise, UNIX's answer to composing programs is shell: a weak, underpowered, insecure language full of gotchas that has to shell out to a million sub-languages with different syntax and semantics to do basic things, and which provides no common substrate of conventions and interoperability between components that are supposed to "compose."

In my opinion, a better solution to each of these examples is available, and exemplified by Emacs, as the last heir to the Lisp Machines:

• Emacs breaks all functionality down into functions, which can be used handily as tools, but which don't come with the costs of separate processes/programs. It also means that complete, holistic applications can be written for Emacs and still remain composable, since all of their internal functions are exposed to the whole system to use and reuse and script and automate in any way desired. This means that there doesn't have to be an intentional attempt to expose an Emacs program's separate functionalities as sub-commands, or a tension between large integrated programs and small composable "do one thing and do it well" programs. You can have both. (Emacs also has powerful process manipulation capabilities and is not afraid of shelling out, too. Emacs in fact makes an excellent shell.)
• Emacs provides a data interchange format with all of the benefits of text and none of the downsides. It is flexible, easily reinterpretable, composable, human readable, and simple, but has the capacity to easily encode structured data and the semantics of the data provided out of band and in a way that can be reliably communicated and understood within its environment.
• Emacs provides a computing environment and language that does functional programming (which is what the UNIX philosophy really is is) better than Bash. It can compose functionality (processes and functions) and transform data in a much more powerful and ergonomic way.

A lot of people criticize Emacs's use of the gap buffer, and suggest that it go with a more complex data structure at the core like ropes. While I think there can certainly be room for improvement with this core data structure, I don't think ropes are a good solution, and I think this is far from a crippling issue. Let me start with the second point first.

One of the biggest arguments against gap buffers is that they're simply not optimized for multiple cursors. I'm not a big fan of multiple cursors (as opposed to kmacros and occur-mode), but more importantly, gap buffer multiple cursors performance doesn't seem noticeably worse than ropes for most reasonable editing situations on a human scale. Just look at this graph:

I'm eyeballing it here, but it looks like the scaling factor is around 200µs per 6000 bytes. If we say that the threshold of human delay perception for something that isn't extremely reaction-time intensive like gaming is around 50ms, then cursors can be 150,000 bytes, or about 12,500 lines (assuming 120 character lines of code) apart before the delay even becomes noticeable to human perception. With the less naive multiple cursor editing system suggested in that same article, that delay can be cut down by 30%, as well, meaning a 16,250-line separation before the difference even becomes noticeable to the human brain. And you're not going to be using multiple cursors all the time, so a barely-perceptible amount of lag, say 100ms, as you type when using multiple cursors is hardly an issue – which raises that ceiling to 32,500 lines of code apart.

Which raises the question. Who in the hell is using multiple cursors that far apart? The big benefit of multiple cursors is that you can see the edits you're making being made live in all the places you're performing an edit, so that if something goes wrong you can respond to it immediately instead of having to re-record your keyboard macro or what have you, but what font size/monitor combination could possibly show that many lines at once? And if you're skipping around a file viewing only a few cursors at once as you make an edit, wouldn't a keyboard macro be essentially equivalent anyway? More than that, if you've got a file that big and you really want to use multiple cursors for some reason, why not create an *occur* buffer with all the lines you'll be changing, edit that with multiple cursors (likely to be extremely fast) and then write all the edits out at once, which will take less time in total for the gap buffer to do? And that's not just a performance optimization, that's actively better than the alternative, since with an occur-mode buffer there's actually a snowball's chance in hell you'll be able to actually see what you're doing with all those cursors (and so not negate most of the point of multiple cursors)!

Moreover, in my personal opinion, multiple cursors are overrated:

1. Having to pay attention to every place where I want to make a rote macro-like change at once as I'm making the changes, cycling my eyes between all the lines and trying to keep track of all of them, is a lot more stressful for me than just recording what I want to do, creating an occur mode buffer of all the places I want to do it (or just using isearch to jump between them), and doing the changes one at a time, responding to any accidents or special cases in each line one at a time as they show up, instead of having a big mess appear all at once in several lines. It's not even more work, since to create multiple cursors in widely separated places you'd need to use search anyway.
2. Additionally, with keyboard macros, there's an easy and natural on-ramp to making whatever you did useful later, through naming the macro, saving it to a register, or even converting it to Elisp code, instead of the operation you did being temporary and ephemeral, limited to the specific instances that you wanted to deal with in one moment.
3. Speaking of that, keyboard macros have much greater versatility, at least in Emacs, where they can run any keyboard shortcut or Emacs command, not just edit text in a specific place in a buffer. Thus you can use the same facility you use to automate editing text to automate your editor.
4. Moreover, with Emacs macros at least, it's trivial to structurally edit macros, instead of needing to record them, if something goes wrong, so it's easier to respond to mistakes – not quite as easy as multiple cursors, but I think the other benefits outweigh that.

In addition, it is my opinion that using gap buffers is actually a really savvy development choice. The reason is that they're dirt simple, and more than good enough at human scale, in comparison to other popular data structures which are much, much more complicated to implement and, while they do have benefits at the very high end, tend not to show those benefits most of the time. Moreover, gap buffers have extremely low constant costs, versus other more complex data structures which have a high constant factor, and require a ton of upkeep and maintenance and can get into "bad states": https://coredumped.dev/2023/08/09/text-showdown-gap-buffers-vs-ropes/.

There are some data structures that keep many of the benefits of gap buffers but can alleviate a lot of the problems Emacs has with long lines and non-local editing, however. For instance, there's the Cluffer.

The other environment that many tech-savvy people tend to try to live their whole lives in, that offers a coherent integration between everything and a limited but flexible set of core components, is the terminal/shell. I think I've given a fuckton of evidence on this page (and in my blog post on this) that, as a text-oriented computational environment, Emacs is infinitely superior: its component pieces are fully transparent, scriptable, malleable at run time, far better integrated, can communicate using a better data format, and so on, and Emacs itself is a far superior shell. Here are a few more reasons:

• While terminals are out here emulating dot matrix printers from 1982 (that have to split images up into character-sized sections and only support 6-bit color, can't be interacted with, and need to be transported as ANSI escape codes in-band) in order to get image support, Emacs can represent clickable, draggable, hoverable, right-clickable, etc arbitrary UIs with SVGs (see the next section), rich text, images, PDFs, clickable buttons, and more.
• While shells are trying to use ncurses and readline to give you some kind of acceptable autocompletion support, Emacs can give you the full power of your IDE in your shell.
• TUIs in the terminal all have to manually hard-code keybindings, instead of exposing their functionality as commands that can be arbitrarily remapped by the user at the computational environment level, which also means that while Emacs can guarantee consistent keybindings, users of TUIs just have to hope that everyone agrees on a common standard (and interprets it the same way).
• TUIs are not usually very scriptable or interoperable under a terminal, so you have to choose between a teletype level interface (shell commands) that offer scriptability and interoperability, or an MS-DOS level interface that offers none of that. Emacs can offer you TUIs that are fully as interoperable and scriptable (even allowing you to take the UI generated by one application and hand it to another, or export it yourself for manipulation and editing, or have multiple interpreting and working together in the same UI).

If you've ever felt the desire to live in the TTY, consider living in a fullscreen Emacs window (or EXWM) instead.

One of the really interesting little things that I've seen on the margins of the Emacs world is people making use of the fact that SVGs are a really good medium for drawing arbitrary graphical user interfaces, since they allow drawing arbitrary shapes, colors, gradients, and text, in a way where it is clearly structured and you can assign relative constraints and sizes, and where that structure is coherently maintained instead of being lost when drawn to a pixel image or something, and the fact that Emacs actually allows you to detect arbitrary mouse events with precise pixel locations and supports operating system context menus and menu bars to construct arbitrary user interfaces embedded within Emacs. An example of this is Emacs Easy Draw:

As you can see, this looks and functions like a real interface, no text-mode funny-business or shenanigans.

Another, more minor, example, can be found here, where messages in the Emacs echo area are given full GUI-level graphics and layout capabilities.

I think key to why this seems to work so well is that it's actually really easy to build SVGs in Emacs Lisp, since SVGs can be represented more meaningfully as data structures with semantic information about what they're trying to depict (i.e. what shapes, what text, where the boundaries of them are, how they're translated and rotated), so it's easier to construct them programmatically, and since they're a symbolic tree structure very friendly to Lisp's native data structures, and Emacs Lisp's macro facility makes an SVG DSL quite easy. I think the other reason this is so profitable is that, since SVGs are a limited primitive, it's easy to pull semantic structure and meaning back out of them, when for instance the user clicks on a location within them, or when things need to be changed. If we were trying to use regular pixel buffers, all of this would be a lot more processor intensive and unwieldy.

The possibilities with this are honestly endless. Fully-featured Jupyter notebook style inline widgets and interactive graphs for org-mode, embedding more fully-featured SVG and even bitmap image editors, Possibly even using SVG as the basis for rendering full HTML webpages inside Emacs? Obviously, building on all of this will take an absolutely gigantic, humongous amount of work to actually build the things that use this the way I'm suggesting, but the point is that the potential, the capabilities, are absolutely there.

Of course, there are tradeoffs to this. SVG-based interfaces have the disadvantage relative to something like Xwidgets (which allow you to propertize text with GTK+ widgets) that they aren't interoperable with the host operating system, and we all have to build those widgets, and their interactivity, ourselves, from scratch. However, the advantage relative to Xwidgets is that it's inherently more self-contained and thus more cross-platform, relies on fewer external variables (e.g., relying on GTK and whatever other UI toolkits Xwidgets would need to use to support other platforms to even continue supporting this and not change so much that maintenance is prohibitive, as well as needing to rely on external platforms continuing to allow this), and the entire set of UI widgets, and most of the interactivity and functionality, would be writable in Emacs Lisp, meaning that maintenance and improvement of an SVG-based widget library would be open to far more Emacs users, as well as much easier and quicker to write and experiment with, and in addition also meaning that these widgets would actually be comprehensible and accessible to the rest of Emacs, instead of black boxes.

Another alternative for embedding arbitrary user interfaces within Emacs is turning Emacs into a Wayland compositor. This has many of the downsides of the previous option – interfaces added thusly being black boxes to Emacs Lisp, difficulty of contributing, external dependencies – but has the massive advantage over both SVG interfaces and Xwidgets that it allows importing other interfaces, like Jupyter itself, or Inkscape, or whatever, wholesale into Emacs without the need for extended development. With a little additional elbow grease, this approach could even insure that such imported applications could not only be embedded in Emacs text, managed like Emacs buffers, etc, but be ensured to have consistent keyboard commands. However, ultimately, they'd be even more of a black box to Emacs than Xwidgets would be, making it so that such an approach would probably lead to turning Emacs into a window manager more than actually integrating external things successfully into it. Unless the things that were integrated were written specifically for Emacs, anyway, but then you might as well use SVG. (Unless you want to do 3D rendering or something, which could actually usefully take advantage of Emacs being a Wayland compositor – maybe the ideal is a combo of EWX and SVG)?

Making a full UI toolkit via SVG in Emacs Lisp is honestly an interesting project to look into in the future. It might also be possible to use a headless browser or reasonably complete layout engine to render web page HTML to SVG which Emacs could then display, allowing a faithful 1-to-1 reproduction of HTML pages, just like Xwidgets offers, that also allows Emacs to inspect the content of those pages! Unfortunately, according to a few cursory searches, it looks like most command line HTML to SVG tools are quite dead, and since command-line processes are the easiest to control for Emacs, that does present a problem. However, I maintain this remains a feasible theoretical possibility.

There's a lot of discussion in Emacs community around how Emacs should become multi-threaded. While I think a lot of these ideas are interesting and could work, I think they're ultimately misguided. Most of the fundamental appeal of Emacs is that, at its core, it is a big, huge ball of mud – and by mud, I mean global mutable state. The fact that it's just this huge ball of state that anything can access and modify at any time, from anywhere, and immediately see the changes live, without hindering the access and modification of that state by any other part of the program, is what allows Emacs to be what it is in the first place. But that kind of global, shared mutable state is just fundamentally incompatible with multithreading, since it leads to race conditions, instability, memory corruption, conflicts, and in general just extremely difficult to track down and resolve bugs. And any solution to that problem would fundamentally chip away at what makes Emacs unique:

• Implementing zero-shared-memory message-passing, like you can find in languages like Erlang: essentially reduces being able to modify the global state, or the state of other programs, to a limited, rigid, non-transparent API – at that point, you might as well move packages out into plugins and extensions communicating with each other and the editor over RPC like NeoVim does.
• Implementing exclusive memory access systems like locks and mutexes on buffers and their associated local variables: drastically reduces the usefulness of Emacs's unique (compared to Vim and NeoVim at least) ability to run multiple modes (one major mode plus N minor modes, or even multiple major modes on different regions) on a single buffer, imbuing all kinds of different overlapping meaning and functionality into buffers in a way few other editors can match. Additionally it doesn't solve the problem of dealing with non-buffer-local variables, and introduces the possibility of deadlocks, which are an almost as severe problem as race conditions!

Instead, I think Emacs should lean into what it already does well: shelling out to external processes when parallel execution (for example, super heavy long running computations) is needed. This is already an extremely common pattern in Emacs programming, and one that I think should be enhanced to make as easy and ergonomic as possible, through two methods:

1. Emacs Lisp's standard library already has extremely powerful primitives for this kind of functionality, but they're ultimately pretty unwieldy and verbose, require a lot of boilerplate and esoteric knowledge about process-management terminology that may seem natural to almost any computer nerd worth their salt but will be alien to the humanities end of the Emacs user base, and just aren't good enough yet. Thus I think integrating things like emacs-aio, which allows you to do async (based on Emacs generators), mutithreaded, and multiprocess programming using a common library interface that's extremely easy and generally works and looks like synchronous code that we're all familiar with, and integrates deeply with Emacs's command loop, is probably the way to go.
2. Allowing Emacs Lisp programmers to shell out to external Emacs processes to do work more easily by including something like the emacs-async package – but that can allow Emacs instances to communicate data structures (and even closures and callbacks) using raw bytecode instead of needing to serialize and deserialize S-expressions from buffers – in the Emacs Lisp standard library. This gains you the asynchronous programming benefits of multiprocessing and shelling out, without having to lose the unified language, set of data structures, interoperability, and consistency, of the Emacs computing environment.
3. Creating a pool of Emacs worker processes that can all pull jobs from a central queue (and maybe do work-stealing between each other), for the purposes of making point 2 more efficient.
4. Making the core of Emacs (the display code and Lisp interpreter) more multithreaded. This shouldn't effect what "user space" Emacs is like at all, but could prevent things like long lines or garbage collection from blocking everything else.

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 suggestion above.
   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!

One of the most common philosophical misunderstandings that I see people have about org-mode is that they assume that it must have a particular intended workflow, like any other literate programming, personal information management, project planning, note-taking, or other similar such system.

This makes sense, since org-mode does represent a cohesive thing, the closest analogue of which, for most people, is some kind of application: after all, it's not just a notation, but a set of interfaces, functionality, and presentations deeply integrated with that notation – possibly integrated to the point of the two almost being completely identical, since anything that isn't literally org-mode.el really isn't "org mode," even if it uses the same syntax.

Despite making sense, however, this misunderstanding causes problems for people trying to figure out how to use the system. It's often unclear to them how to even begin, because they're looking for a specific place to start or way to approach using the system, or expecting to find a tutorial that explains the expected workflow from beginning to end. Instead, all they find is a 600 page manual documenting a dizzying parts manifest of features the vast majority of which they won't even be able to absorb, let alone intuitively understand how these strewn-about component parts in the abstract might possibly be assembled into a concrete, working workflow. This often leads to questions about the "right" way to use it, the "best" way to achieve something, and in searching for answers they'll stumble across a Babelesque bazaar of different responses, most of which don't go into detail but simply recap the more basic, core features org-mode has which every one uses, without mentioning the one or two features that might actually be revolutionary for that specific prospective user's workflow.

The result of this is that most people who use org-mode tend to assume it can only be used in one fairly rigid way – the sort of community-folklore way of using org-mode that's sort of developed as people with that workflow (including the authors) try to explain what org-mode is to others by example, and then those people adopt that workflow as rote because they're used to tools and systems with particular expected workflows – and if their desired workflow doesn't fit with that folklore org workflow, they assume that isn't a way org can be used and move onto some other system. For instance:

• Most people don't know that org links can be created to refer to, inserted in, and followed from, any file at all, not just org files, making things like Denote and Howm, the main claim to fame of which is allowing you to put their own custom link markup in any other markup file to link between things.
• Or that you can label org headings with GUIDs and allow any heading in your agenda directory to be a suggestion when completing GUID-based links, as well as setting up a capture template that prompts you for a file name in your agenda directory whenever you capture something new, allowing you to build a Zettelkasten note system where each note is in a separate file but can link to any other heading in any other note as easily as if it was in the same note file, and where GUID locations are stored in a database for easy retrieval, meaning org-roam is largely unnecessary unless you have a truly gigantic number of notes.
• Nobody seems to realize that with a simple regex modification, headings referred to only by tags or GUIDs, without actual titles at all, are possible in org, making EKG largely pointless.
• Similarly, nobody seems to realize that you can use the built in org publishing system for publishing blogs without needing to even write any new code, and RSS feeds with a 40 line function, so all those org static blog publishing systems are totally unnecessary.

All of this functionality is possible because, like Emacs, org-mode is less an application with a specific purpose and intended workflow, and more a whole system for doing a related set of tasks. Where Emacs is a system for manipulating rich text, structured data, file systems, and operating system processes interactively in a malleable runtime environment, org-mode is a system for creating and manipulating structured rich text hypertextual information and viewing and exporting it in various ways, interactively. (You can see why org-mode and Emacs are such a natural fit!) It doesn't have "a workflow" because what it offers instead is an extremely powerful general markup language for expressing highly structured hypertext information (both mainline content and metadata), a system for parsing, reading, arranging, and manipulating that structure, and a set of interfaces for that functionality. What you do with that, how you use it, is completely up to you. There are an infinite number of ways to use org-mode, and the difference between any given workflow in org-mode is just a difference of habit, mindset, and a little Emacs Lisp.

What's awesome about this is that tools for thought, systems for managing your thoughts and information, are at their best when they're monolithic, fully integrated into a single system just like your brain is so that you can easily create links and references and relationships between anything that you're thinking about or having to manage, easily able to flow between different styles of workflow and thinking regarding information management depending on what makes sense for the given thing you're grappling with or even how you're feeling that day, or how your workflow changes over time, without ever locking you into one thing. A general purpose information management system that is flexible enough to change with the context and change with you, and handle any kind of information management task you might need, will be infinitely more useful than a bunch of rigid silos, over a longer period of time.

One of my biggest pet peeves is people not understanding and making use of all of the powerful functionality that Emacs already provides. (That's why I created Quake Emacs). So many packages have been integrated into Emacs's core, and Emacs itself has been extended with so many incredibly powerful features over the forty years of its evolution, and yet so many of them are poorly documented or marketed, off by default, or badly configured out of the box, that oftentimes people prefer to use huge overhaul packages that complete reinvent the wheel, replicating functionality that could be had with core packages.

What's the actual problem with this besides just wasted potential, though?

In my opinion, it's really two things: one, these big reinvent-the-wheel packages usually require a lot more maintenance than they would if people built on the shoulders of giants, configuring, or improving what's already a part of Emacs, since these packages typically have to reimplement the built in functionality and then go to extra effort to integrate with Emacs on top of it, when all that effort could go into improving the stuff that's already being built and maintained in core Emacs, and two, those big overhaul packages usually don't integrate as well with core Emacs and other packages, possibly also requiring any packages that want to hook into their new more advanced functionality, rather than the functionality that's on by default in Emacs, to explicitly depend on these packages, which makes the Emacs ecosystem a lot more brittle and less modular and composable.

However, there is a new breed of overhaul packages that at least don't fall foul of the second issue, like Vertico and orderless.

One of the primary wonders of computing is that creation on a computer is essentially completely free, once you have one – the world of information is a post-scarcity one where the only cost is your time, and that's it. Bits can represent anything, from prose to poetry to images to film to interactive games to music, and bits can be created and infinitely duplicated (taking poetic license here, don't come after me, I know they're technically being modified not created) at zero cost, on your own computer or between any other person's computer in the entire world. Even distribution, in the digital age, is nearly free – pick up a $35 computer on eBay or from your nearest surplus store and run Linux on it, every Linux distro comes with a network server – even if getting attention to that distribution isn't.

The other primary wonder of the computer is that it is an infinitely flexible information processing and communication machine – a meta-machine that, if you can describe a behavior, can instantly become a machine-to-do-that-behavior. There's no limit: as long as we understand what we want the computer to do, as long as we can describe the way we want it to process information, or how to link information to behavior, the computer can automate it. There is no fixed purpose to a computer. Thus computers can be a great help in people's everyday lives (as long as they have to communicate or process information regularly), freeing the user from time wasted with repetitive drudgery, giving the more time to think and play and create, or spend time with their friends and family, or hike around in the outdoors.

I feel that this has been lost in the modern era of personal computers, where user interfaces revolve around things like start menus, task bars, desktop folders, and home screens, oriented around launching circumscribed applications for specific tasks (usually content consumption) that present no affordances to be easily wired together or scripted or pass information quickly from one to another for processing, instead of notebook interfaces, shells, or REPLs. Don't get me wrong, there are a huge number of ways in which the fundamental metaphors, design, and capabilities of personal computers and their interfaces have massively improved, and we should preserve those where we can, but my dream operating system would be oriented around a notebook-centric interface, something like what Karl Voit calls an application-less system.

In a document-centric operating system, you should boot up your computer and be immediately presented wixsth something like a notebook interface: a document for creating things – anything you can imagine.

• You should be able to just go right ahead and start typing if you want to write prose, take structured hierarchical notes or unstructured Zettelkasten notes, register rolodex-style grouped metadata entries, list tasks and subtasks, document upcoming events, or create a presentation. This should be done with simple plain-text markup (for maximum versatility) but still offer deep structural editing, manipulation, and analysis, so that the user isn't stuck doing all the legwork themselves.
• You should be able to open existing notebooks from previous sessions, or request various views of cross sections and queries on every notebook in your entire system, correlating all the information and content you have created easily and coherently.
• You should be able to follow hyperlinks inside and between notebooks, and to applications and external websites, and even to activate code or UI elements or run key commands, to correlate together as much information as possible.
• You should be able to include documents from over the network transparently into your notebook without having to explicitly manage downloading and attaching them.
• If you want to run code, you should be able to create a code block for any language you have installed on your system and want to use immediately, in line, without having to open a separate editor or IDE program or terminal or REPL, and when you're editing that code you should have access to full syntax highlighting, refactoring support, and autocompletion.
• Then you should be able to just run that code block with a simple key command and see the output – even if that output is an image or a UI widget, which you should be able to interact with – and then plug that output into further code blocks (even if they're for different languages) or tangle a source code file from your code blocks for contribution of version control.
• Controlling your system should be actionable through writing whatever code or commands you want to execute in a code block or, if it's small enough, directly inline anywhere in your other text and hitting a key command to execute it, as well as through a fuzzy completion command palette for simpler single commands. You should be able to control other computers you own transparently over the network from this notebook interface.
• All applications should be accessible through running a command in the palette to open it in a new split or on a new workspace, or running it inline in the existing notebook interface to get an embedded interface, if that makes sense.
• Every time you open a new window or switch to a new desktop, either an existing notebook or interface, or a fresh new one, should be presented, as makes sense.
• The environment should offer a means of recognizing patterns in the text you've entered (or semantic metadata or markup on that text) in your notebook and turn those into powerful hyperlinks with a default action and a semantically aware and extensible list of other actions, so that your notebook system can be highly hyperlinked and manipulable with minimal intentional markup.
• If the user wants to view things like web pages, images, or videos, that should be easily possible either in a new window or inline with the notebook – as they desire – but the notebook should allow the user to toggle "read only mode" off on any of these things, at which point the piece of content will be automatically saved and an editing mode entered where they can annotate, edit, modify, or expand on it.
• Anywhere in the user interface of any application or in any notebook, it should be possible to store a hypertext link to that location and add it to any other notebook.
• Anywhere in your interface it should be as easy as possible to open a new or existing notebook for adding-to.
• Notebooks that contain hyperlinks that run code in the system language – which should be able to launch and control any application, modify or control the system itself, modify the notebook, including changing or adding other hyperlinks or code blocks and running them, as well as opening new documents internal or external – could allow users not just to script things but to trivially construct their own user interfaces for various everyday purposes in an essentially free-form, low-code way, like the beloved classic Macintosh HyperCard system extended to the entire operating system.

Combined with the properties of a homogeneous, open, malleable system with true homology between all user interactions and how interfaces are actually implemented and scripted, I think this interface would maximally empower users: it could incline them toward creation over consumption, specifically creation of their own content, and give them an up-front way to learn how to control, modify, and automate their system, so that they aren't stuck just pulling a lever that's now digital instead of physical.

There is only one system I know of today that allows an experience like this: Emacs. Either through packages like org-mode (& org-babel, org-agenda, org-capture), Embark, org-transclusion, and of course built in functionality like eval-last-sexp, eval-defun, the *scratch* buffer, and TRAMP, or through the less powerful, older, and more obscure, but also much more integrated and versatile GNU Hyperbole.

There are two approaches to adding tools and functionality to Emacs.

The first one is to take an existing program with IPC functionality or a command-line interface – usually most profitably the latter, for as much as I think the UNIX philosophy is incomplete and short-sighted, the idea of making sure that as much program functionality as possible can be called from the command line, and having everything communicate through text streams, ensures the composability and scriptability of programs far better than most other paradigms – and write an extensive library of Emacs Lisp functions and defcustom variables wrapping that functionality, providing a way to deeply script, control, and modify the behavior of that program, as well as a set of transient, hydra, or in-buffer user interfaces for that program.

The other is to completely reimplement the functionality of that program in Emacs Lisp from the ground up, using the powerful standard library and platform-agnostic language runtime provided by Emacs itself, providing a self-contained package that functions like a fully independent program installable through the magic of use-package or package-install.

Each of these approaches has benefits and drawbacks.

The first approach's main benefit is that it allows Emacs to take advantage of the already-existing powerful and featurful tools that exist outside of it, while still lending most of the benefits of the Emacs computing environment to those tools. Thus, Emacs can benefit from all of the functionality that those tools have already implemented, and all of the new functionality that they will implement in the future, essentially for free. The maintainers of the Emacs package also get to benefit from sharing the maintenence burden for that functionality with others outside the very small Emacs community, and users of the Emacs package get to benefit from using the same tool that a large community of non-Emacs users also use, such as greater interoperability, more documentation, and more access to help. The main drawback, of course, is that since the tool is not implemented from the ground up in Emacs Lisp, only the functionality and customizability that is exposed through its IPC or command-line API can be accessed through Emacs Lisp. Deeper core functionalities can't be changed, and new functionalities must be layered on top in terms of the actual capabilities of the program itself. In essence, it works like adding more core C code to Emacs, placing an extra boundary on what it can do. The secondary drawback is that having your Emacs computing environment rely on external tools can be a recipe for fragility when you take it with you from place to place, since the programs you've made it rely on may not be as platform independent as Emacs itself is.

The benefits and drawbacks of the second approach are essentially precisely the inverse of those of the first approach: while implementing a tool completely in Emacs Lisp means that it is completely hackable from bottom to top, and much more self contained in the cross-platform runtime Emacs provides, it means that the burden for feature implementation, improvements, and maintenence falls entirely on the package authors, and the burden for documentation and user help falls entirely on the much smaller user community, and interoperability with what other people are using is sacrificed. There's also another drawback to be considered: the fact that, while Emacs Lisp is certainly not the slowest language around – it's a lot faster than Python or Ruby, which are both used to build quite large applications themselves – it's still a lot slower than you might want for very large and complex user-facing applications, especially in a painfully single-threaded environment like Emacs.

As a community, there's no need to choose between these two strategies wholesale, of course; for any given thing you want to do, packages that embody both – such as Gnus (the second strategy) versus Notmuch or Mu4e (the first strategy) – will always exist to choose from, and that's a very good thing! From a user perspective, which of these strategies to choose will depend on one's personal preferences and assessment of uses and needs on a case by case basis.

However, while I don't ever want packages using the first strategy to go away – I use Gnus without anything like offlineimap myself – I do believe that new package authors should strongly prefer the first strategy over the second. While it does compromise the core values of Emacs, the entire history of GNU Emacs beginning with its own core being written in C is one of compromise, and until several issues at the core of Emacs are resolved, that compromise must continue in the name of making sure that Emacs remains pleasant to use as well as powerful.

In this case, compromise must be acceded to because of the fundamental truth that Emacs is a very small (but dedicated) community even within the niche community of text editors, so we simply don't have the resources or manpower to maintain things and establish interoperable standards on our own. To see the truth of this, just consider CEDET, which was an effort to expand Emacs with IDE-like capabilities including project management, language-aware but agnostic source code analysis for refactoring, jumping, and completion, and a lexer and parser generator for language-agnostic structural editing: it quickly died and became abandonware, because no other communities were using or contributing to it and no languages were interested in supporting it just to help the Emacs community out, so all the work fell exclusively on the Emacs community and it failed to boostrap enough interest. Compare that to the success and revitalization Emacs has seen in recent years thanks to the adoption in core of LSP and Tree-Sitter, standards providing the same functionality that were instituted and supported by other editors such as Visual Studio Code and NeoVim, and the greater success of smaller and more focused packages for single IDE features like Treemacs and Projectile. Adopting technologies and programs used by other communities ensures that your package will have a much longer, more reliable, more robust life, which reflects on Emacs's usefulness and longevity! Furthermore, the first strategy only enhances one of the unique features of Emacs, which is that it is essentially a new and different kind of shell, not just a hermetic computing environment (the most similar thing I know of outside of Emacs is Acme, although it suffers from UNIX philosophy nonsense), so it's not a pure loss.

The similarities between Emacs and Acme ( Acme was created as the premier visual text editing environment for the Plan 9 research operating system at Bell Labs) are fascinating case in multiple discovery not unlike both Liebnez and Newton independently discovering calculus: both have the otherwise very unique property of being most commonly used as text editors, but under the hood actually being malleable, programmable, text-oriented computing environments designed not just for reading and editing text but also managing the filesystem and external processes and the interactions and composition between them, all within a unified window management and user interface paradigm.

While this fact is not part of the official marketing of Emacs, it is commonly known among the community. As Irreal, a pillar of the Emacs community, states:

It is […] a Lisp interpreter specialized for dealing with text that has an editor as one of its built-in applications. […] I prefer to think of Emacs as a light-weight Lisp machine suitable for many tasks. […] Regardless of original intentions, Emacs today certainly embodies the notion of being “an extensible environment with text editing as a feature.” But it’s even more. At least for many of us.

Meanwhile, this fact is expliclitly part of the core intenton of Acme. Just look at Rob Pike's original paper on Acme, where it says:

A hybrid of window system, shell, and editor, Acme gives text-oriented applications a clean, expressive, and consistent style of interaction. Traditional window systems support interactive client programs and offer libraries of pre-defined operations such as pop-up menus and buttons to promote a consistent user interface among the clients.

Also not unlike that simultaneous discovery, one of the inventions was clearly superior to the other and went on to have a much longer history, and the other quickly died out and is mostly only of historical interest. Consequently, a lot can be learned from their differing philosophies in how they approached this common idea. I'll briefly take a look.

First, since I don't feel like into detail explaining precisely how Acme works, because I feel like that would distract me even more from the point of this section than I already have been over the last several minutes writing it, I recommend reading this post to familiarize yourself with the basic concepts before moving on.

Now, on to the meat of my critique:

1. Acme tries to use the mouse for as much as possible. While this is extremely interesting, and some will defend Acme's use of the mouse till their dying day, I think this is an unsuccessful experiment. The use of mouse button chording does expand the bit rate of mouseing input somewhat (by exactly three bits!) but not by enough to make a significant dent in the vast chasm between the information throughput of a keyboard and a mouse, and it doesn't begin to address any of the other problems the mouse has in comparison to the keyboard – most devistatingly of all for a text-focused application being the need to constantly move one hand back and forth between the keyboard and the mouse when switching between editing/navigation and entering content.
2. Despite provideing a very malleable interface in the form of its tag lines, which you can put any commonly used commands you want access to in, and the fact that its text windows are live text stream devices so it's easy to embed anything that can operate over a TTY in them, and a deeply programmable environment through point (3) below, Rob Pike had very specific user interface design ideas, and decided to skip out on UI programmability and malleability in favor of enforcing them. For instance, he made the intentional choice not to support syntax highlighting or changing the color scheme. Judging by that approach I deem it unlikely Acme would have eventually come to support any of the modern display and fontification features which enrich our experience of Emacs today, either. This may seem like a minor point, but it's rather fundamental: while Emacs seeks to extend its display capabilities as much as possible while maintaining consistency, composability, and reflectability by ensuring a basis in a common set of underlying systems (text propertized with structured data), Acme seeks to maintain consistency, composability, and reflectability of its interfaces through outright hard-capping the capabilities of its interface entirely. This may be part of why Acme died: its inability to adapt to new capabilities and new knowledge (such as the fact that syntax highlighting is actually very beneficial).
3. Instead of having a language built into it that lets you program it, and using that language to import and control external programs, as Emacs does, Acme instead exposes a simple command language and the event logs, text content, and so on of each of its windows as filesystem devices so that separate processes can read from and write to those devices in order to control it via pure text streams. This means that nothing fundamental about the editor can be modified or changed this way, so the editor must be as minimal as possible, carrying as few features as it can, in order to outsource the rest to more changeable programs. The problem with this is that:
   1. Since these are entirely separate processes communicating over raw text streams with Acme, there is no way for these programs to fundamentally modify any of Acme's core functionality or concepts. Everything must be implemented in terms of Acme's necessarily ecruciatingly limited set of concepts and user interfaces, which means that more complex functionality such as better display capabilties (as mentioned above), changes to how the window layout works such as autocompletion and documentation popups, modifications to how input is processed at a fundamental level like transient menus or hydras or text based UIs like magit, are all nearly impossible.
   2. While a feature can be made available to the user through a shell command that runs a process which can communiate with Acme, since all these processes are launched by the user completely individually, they have no way of knowing about each other, let alone meaningfully sharing information about their current internal state and provided functionality.
   3. Furthermore, if a feature is added to Acme by way of an external process, due to the previous point, other processes still won't be able to know about it or use it in any robust way that isn't extremely brittle, like asking the user to list what commands for Acme they have available manually in a text file somewhere.
   4. As a result, Acme's extensibility and thus longevity is fundamentally hamstrung: imagine trying to replace some core user interface concept in Acme with something better, like Helm or Vertico do with Emacs's built in completion system, or hook into all possible completion interfaces across the whole program to add more annotations useful to the user, as Marginalia does.
4. Having to use the shell to program Acme exposes the user to all of the flaws of the UNIX environment, full bore, like a firehose. An Acme user will have their fill of a cryptic, underpowered, gotcha-filled shell language that requires you to awkwardly compose together programs that all format their data in completely different ways using dumb text-munging via esoteric commands with even more esoteric arguments. Ever wanted to have to run xargs or figure out the pattern language of find or write AWK scripts or figure out whatever the hell tr does in order to use basic functionality in your editor? Then you'll enjoy Acme. Then there's the added insult to injury that these commands are somewhat unergonomic to run from the editor since, unlike with a Lisp, the borders of any given expression are not clear in a shell language, so the whole shell expression must be selected before it can be run each time.

I think the differences between Acme and Emacs are the perfect case study in the differences between the UNIX philosophy and the Lisp Machine approach to computing systems. And I think it's telling that one survived the death of its host system and has continued to be used for 40 years, and the other did not and has not.