“
Why rewriting Emacs is hard,” by
@kana Yes it is, I can tell you from experience. Of course, I was never under any illusion that it would be easy.
@kana , a.k.a. “Gudzpoz,” wrote a blog post which was shared on Lobste.rs, and they kindly mention my own Emacs clone Schemacs, though they refer to the old name of it “Gypsum” because they are citing my EmacsConf 2024 presentation done before the name changed.
It is a pretty good post going over some of the odd details about how Emacs edits text, e.g. the character range is from 0x0 to 0x3FFFFFF
rather than the Unicode standard range from 0x0 to 0x10FFFF
, issues with using a gap buffer as opposed to a “rope” data structure, attaching metadata (text properties) to strings to render different colors and faces, and issues with Emacs’s own unique flavor of regular expressions in which the \=
symbol indicates matching on the point in the buffer. (I did not know about that last one!)
Apparently, they know these things because they are also working on their own clone of Emacs in Java for the JVM called Juicemacs (the name “Juice” upholding the theme of Java-based applications being named after drinks), and I deduce that their approach is to read through the Emacs C source code to ensure better compatibility. This is now the fourth modern Emacs+EmacsLisp clone that is still under active development that I know of, fascinating work!
My approach is to clone Emacs well enough to get it to pass regression tests, and I don’t read the C source code, I do black-box testing (because those tests become regression tests for my own source code).
Also, the goal with the Schemacs project is more to provide a Scheme-based Emacs that is backward-compatible with GNU Emacs. You use Schemacs because you want to program it in Scheme, not Emacs Lisp, but Emacs Lisp is there for you so you can still use your Emacs config. As a result, I will ignore a lot of these fussy details of the GNU Emacs implementation unless it is going to prevent regression tests from passing.