Emacs in Scheme

During EmacsConf 2024, which was held online in early December 2024, Ramin Honary gave a talk about Project Gypsum, which is his effort to rewrite Emacs in Scheme. Unlike most other Emacs clones, which simply replicate the key bindings, Gypsum is also implementing Emacs Lisp (or Elisp). Honary is initially targeting Guile, which is an implementation of Scheme, but wants to make the code portable to any implementation of R7RS Scheme.

He started by introducing himself as an "Emacs enthusiast since 2017" who currently works mostly with Python and JavaScript. His "true love" is functional programming, Haskell in particular. He started learning Scheme two years ago and has been working on Gypsum for the last year. Honary said that the name of the project is tentative, "naming things is hard", and he is open to suggestions.

Rationale and history

Honary listed a small handful of existing Emacs clones, including Edwin, Lem, JED, JOVE, and others; none of those include Elisp, they simply implement the same key bindings as Emacs. Notably, Edwin is written in the MIT Scheme dialect. The XEmacs fork of Emacs is the only alternative that provides Elisp capability.

In his experience, most people do not use Emacs for its key bindings, however. Instead, the people he has talked to about it use Emacs for the power of Elisp. Emacs is at least as powerful as any of the shells (e.g. Bash) and part of the reason is the availability of Elisp, which can ably control processes, deal with files, configure the system, filter output from commands in buffers, and so on.

One goal is for Gypsum to be able to execute users' Emacs initialization file (init.el) "without significant changes". People invest a lot of time into their Emacs configuration and it is disruptive if they cannot use that when switching to another editor, he said. "So I think a useful Emacs clone would be able to clone Emacs Lisp well enough that you can run your init.el."

Scheme has attributes that have attracted him, which is why he is using the language. "I love its simplicity and its power. It's an extremely well thought-out language." Scheme reminds him of the computers he used as a child, starting in the late 1980s; in those days, it was theoretically possible to understand computer systems from the software down to the circuits. Similarly, Scheme is small enough that "you can read the entire specification and understand it yourself".

He would like to see Scheme have more adoption outside of its academic roots. The R7RS standard has been around for over ten years at this point, but the Scheme ecosystem is still fairly small. His idea is that an editor, possibly with an integrated development environment (IDE), that is built in Scheme might make a "killer-app-like project" that could help spur further Scheme development.

There has been interest in using Guile with Emacs for decades. Honary went through some of that history, including Ken Raeburn's project to write Emacs in Guile, which was active 1999-2009 and is quite similar to Gypsum. In 2009, Guile started shipping with an interpreter for Elisp, which is still being shipped today. He also noted Robin Templeton's work on incorporating Guile into Emacs, which was the subject of another EmacsConf talk.

Along the way, though, Emacs has gotten a just-in-time (JIT) compiler for Elisp, which has become more of a full programming language in its own right. It is, he said, more oriented toward Common Lisp than to Scheme, which may mean that the Emacs maintainers are less interested in using Guile. As far as he knows, though, there is still a lot of interest from the Guile and Scheme communities toward incorporating Guile into Emacs.

Demo

Next up was a demo of what he has working so far. The graphical user interface (GUI) is "barely working" because he has little experience with GTK and GObject introspection. He is using Guile GI, which allows Guile programs to use GObject-based libraries, as the basis for the GUI. Currently, Gypsum can be hard to debug because he does not get useful stack traces when it crashes, which makes for slow progress; he plans to rebuild the libraries with debug symbols so that he can use GDB at some point when that becomes a bigger problem.

From the Guile read-eval-print loop (REPL) in a terminal, he loaded the main-guile.scm file, which brought up a basic Emacs-ish frame. He could type text into it and evaluate Scheme forms from the "Eval:" prompt (via the M-: key binding), though there were some problems with the display of the mode line. There is also a REPL that runs in a separate thread where a user can evaluate Scheme forms in the editor environment. Scheme allows returning multiple values from a function, so he encapsulates those in a list for display. "It's still quite buggy", which he showed by crashing it because a widget was freed too early; he hoped to fix that bug before the video presentation went live.

The Elisp parser in Gypsum is based on the parser in the Guile Elisp interpreter. He has copied the code into his repository so that he can iterate on it more quickly. He has modified the lexer and parser a little. It can parse the subr.el file that provides some basic Lisp functions for Emacs, though Gypsum cannot evaluate that file yet. He has submitted a patch to the Guile upstream along the way as well; contributing to Guile is another goal of the project, Honary said.

So far at least, he has not been successful getting the Guile Elisp interpreter working. Even in Guile itself (using ",L elisp") the Elisp interpreter does not work correctly for him. The code is not well documented and is fairly old at this point as it was developed in 2011; overall, Guile Elisp is rather opaque and he has been unable to get it working reliably—in Guile or in Gypsum.

So Honary has started working on his own Elisp interpreter. It can evaluate some simple forms; he showed a passing test that used progn and setq, but noted that the next test, which used let*, failed because the let* implementation was not yet complete. "Lots of work left to do there."

Plans

He turned to his plans for Gypsum. The first step is to be able to parse and evaluate all of subr.el using his Elisp interpreter. He has set up a testing environment that makes it easy to isolate pieces of that file to try out, but there is much that still needs to be implemented. He said that Elisp has nearly 1400 built-in functions, which is far too many for him to implement on his own; "so if this project is going to be useful to anybody in any reasonable amount of time, I'm going to need help".

His hope is to gather those who are interested in a Guile-based Emacs and build a community around Gypsum. If there is enough interest and people wanting to contribute, "my job will be to document the building and testing process and make sure that it is as easy as possible to contribute code to this project". That includes documenting the system architecture via blog posts and videos.

He plans to prioritize on the built-in Elisp functions that are the most needed for getting to a functional interpreter. He will also be looking for "low-hanging fruit, functions that are easy for people to implement as a good introduction to getting them started on contributing to the project". Eventually, he wants to get the Elisp interpreter to the point where it can run the Elisp regression tests, which are used by the Emacs developers. That testing system is written in Elisp, so it will be useful to get to a point where the Gypsum Elisp interpreter can run it.

Beyond that, the GUI needs work. He plans to get a functional GUI with Guile GI and GTK, but thinks it would be nice to have a terminal version of the editor as well. Before too long, he hopes to get to a point where one can "actually contribute a patch to this project from within the Gypsum editor itself".

He answered some questions after his presentation. He noted that he would like to support other GUI toolkits beyond just GTK and has structured the code with that in mind. Supporting Emacs packages (such as Magit) that depend on external libraries may be somewhat difficult depending on the interface that Emacs uses; directly linking to the libraries from Gypsum is harder, but using the existing Guile process-handling facilities will work fine for, say, executing git. Honary liked the name suggestion of "Schemacs", but was not sure if it had already been used or might be confusing; as it turns out, that name has been used, though that project may be abandoned at this point.

The two Scheme-oriented talks from EmacsConf that I watched were definitely interesting, but there is lots more from the conference for the Emacs-inclined. There were more than 30 talks on a wide variety of topics, from Org mode to regular expressions, literate programming to using Emacs as a book-authoring tool. Those who have read this far are likely to find something of interest there.