[bananamogul]

If I was going to reimplement Emacs it wouldn't be with Lisp.

Is there some reason Lisp is superior to any other general-purpose programming language for text editing? I'm skeptical because to my knowledge, Emacs is the only major text editor written in Lisp.

[Barrin92]

>Is there some reason Lisp is superior to any other general-purpose programming language for text editing?

purely for text editing? No. But that's not what distinguishes Emacs, it's famously very mediocre at it. The point of Emacs is to be a fully transparent, inspectable, dynamic and changeable environment. In spirit similar to Smalltalk systems like Pharo. And for that a Lisp is not the only choice but a very good one.

There's very few languages and environments that facilitate jumping into any place, making a change, compiling or evaluating a block of code or treating it as data and continuing seamlessly.

[antiframe]

> But that's not what distinguishes Emacs, it's famously very mediocre at it.

I disagree. Every time I use another editor I lament missing features when it comes to editing text. Like most editors (vim excluded) have pretty lackluster undo, transpose, case altering, and text reflowing commands.

[NetMageSCW]

An editor environment based on Smalltalk would be very interesting.

[klibertp]

See GToolkit[1] - Lepiter is a bit like that. It's too notebook-y for my taste, but it lets you write and format text and embed any widget. It also uses a native GUI and is not a repackaged browser.

[1] https://gtoolkit.com/

[jdougan]

Did they do anything to fix the OpenSmalltalk VM lamentable keyboard input?

[spudlyo]

It's a product of its time. In the mid 70s when Emacs was originally created, the MIT Lisp Machine Project had already been going for a few years, and Lisp was kind of a big deal at MIT's AI Lab, where it was created. When Stallman started GNU Emacs in '85 or so, he took lots of inspiration from Lisp and those systems.

You can think of Emacs as a kind of software Lisp machine with an emphasis on editing. Although that analogy only works well if you squint or if you don't know a lot about Lisp machines.

As someone who first learned Lisp through Emacs Lisp, I found it fun, well-documented, and powerful. Once you grok the basics of how the system is dynamically glued together, infinitely hackable, and self-documenting it's kind of mind-blowing.

[drob518]

Not specifically superior for text editing, but it has some specific capabilities that make it ideal for making an editing environment. Specifically, it’s great at incremental, dynamic loading of small code snippets. This allows development of Emacs code without having to recompile and restart all the time. In fact, the low-level core of Emacs (buffer manipulation code, regex execution, redisplay, etc.) is all in C. But then those C routines are strung together with Lisp to make up all the high level functionality. Having a dynamic, incremental language is really handy for that. Does it have to be Lisp? No, not necessarily. But Lisp is a great choice.

[internet_points]

The Lem editor[0] and LispWorks IDE's[1] are implemented in Common Lisp.

Still, the reason for choosing a language for whatever are always more social and path-dependent than technical (reason 1: initial developer of whatever really likes the language, reason 2: language is seen as hip within some crowd, reason 3 (later in the game): management feels language is safe). Technical reasons for choosing a language typically tend to be post-hoc rationalizations. (I mean, no sane person would choose Javascript for an editor based on technical reasons alone, yet here we are.)

[0] https://lem-project.github.io/ [1] https://www.lispworks.com/products/lispworks.html

[klibertp]

As much as I love Common Lisp, it's dead. It has 2 orders of magnitude fewer packages in quicklisp than Emacs has in MELPA - and Emacs is an editor, not a general-purpose programming language. SBCL has a handful of devs and moves very slowly - nothing else does at all. Maybe LispWorks, but that's expensive.

CL is also held together - and held back, hugely - by the standard that won't ever be updated. It's good to have it, but there are major omissions (code walkers, MOP) that won't ever be fixed.

As it is now, Elisp is more practical as a scripting language than CL. The gap will only continue to grow. Right now, CL has an edge in parallelism - native threads and mutexes (with all the problems they entail) work there, while with Emacs, the only parallelism you can get is through separate processes. On the other hand, async/await-style concurrency works quite well in Emacs, while in CL you're basically a few macros away from raw promises, and the only real asynchrony is through a pool of threads executing callbacks, and it doesn't play well with conditions and restarts and some other advanced features (notably absent from Elisp).

I love CL, but right now it's aged considerably, lost many of its unique advantages, and has little chance of ever catching up. It's a shame, but using CL in 2026 is not a superpower anymore - it's just one of the similarly-valued propositions, competing with other dynamic languages, still providing a few unique advantages, but even those are being implemented in other languages fast.

[beepbooptheory]

Lisp calls c in emacs. What would be a better language? The code-as-data, data-as-code paradigm fits nicely imo with everything-is-a-buffer. Things like global namespace, hooks, defadvice, would all feel very wrong in other interpreter, and yet seem to make sense in elisp.

[sunng]

Emacs is like a minecraft of lisp expressions.

[0xpgm]

A good reason is that Lisp has almost no syntax. So it can act as a neutral language that is easy to learn for developers from other languages.

[bandrami]

Because it's very easy to generate lisp code. It's meant for metaprogramming

[jimbokun]

But if you were implementing it in 1976 you would have.

[pkal]

But in 1976 Emacs was implemented in TECO. In 1984 it was implemented in Lisp, because Multics Emacs _or_ EINE/ZWEI (Lisp Machine editors) were using Lisp as an extension language, which apparently has shown itself to be useful.

[NetMageSCW]

Consider Lugaru Epsilon - an Emacs style editor that has a C based extension language.

[jibal]

This article isn't about reimplementing emacs.

BTW emacs is written in C.

[NetMageSCW]

No, emacs is pretty much written in elisp. There is a core runtime written in C, but that exists pretty much to run elisp code.

[jibal]

P.S. As for the naysayer: The C code does a lot more than run elisp. e.g., memory management/GC, display and I/O, primitives/built-in functions/subrs, system services.

Even if you interpret emacs strictly as an interpreter of elisp, that interpreter is written in C, not elisp.

If you removed all elisp from the emacs distribution, you would still have an extensible windowed text editor. And you could add any desired functionality by writing elisp. Take C code away and you've got nothing functional.