Editors and code
- Lem (active as of 2022). An editor that works out of the box for Common Lisp but also for more languages thanks to its LSP mode (Python, Rust, Go, Java, Dart, Nim, HTML… with also a directory, markdown, SQL, shell… mode). It works on the terminal and in an experimental Electron front-end. More are in the works. It lacks docstrings and documentation, but its gitter chat is somewhat active and different people showed interest in helping. It has a Vim layer.
It is an easy to install CL editor and REPL, so it's worth checking out.
- LispWorks is a proprietary implementation that comes with its own full-fledged, GUI editor, originally based on Hemlock.
You can find a review of the LispWorks editor on the Common Lisp Cookbook: https://lispcookbook.github.io/cl-cookbook/lispworks.html.
- Climacs is an implementation of the Emacs text editor in Common Lisp with some very interesting features, like incremental re-parsing of the buffer according to syntax rules and automatic indentation of lisp code. At the moment, it is also the most actively developed of the cl-emacsen on this page. Climacs is based on the same philosophy of dividing functions and user commands as Hemlock.
- Hemlock is an emacslike editor that comes with CMUCL, using CLX. Some things are different from modern (X)Emacs, and said to be more akin to older Emacsen. A lot is similar, though. The major difference that users will first note is that M-x commands are "Ordinary English Words" rather than "hyphenated-lowercase-lisp-function-names". This has a lot to do with how commands are implemented as something separate from 'interactive functions' (ie, functions which call the interactive macro to add themselves to the list of available commands). The ZWEI/Hemlock design is actually much cleaner and clearly separates functions from user commands. To the user, the difference is that they no longer have to remember arbitrary function names, but instead just remember ordinary 'names' for operations. As far as keybindings go most of the ordinary Emacs bindings (movement, simple editing) are the same, but more complicated commands (like code reformatting) are going to be different.
- Portable Hemlock (phemlock) is a fork of Hemlock that's intended to run on any ANSI CL that has CLX. Also includes an elisp emulation package from Ingvar Mattsson: note that this is not the same as the CLOCC package below
- Goatee is the text editing component for McCLIM. There's an overlap between McCLIM and phemlock developers, so it's not impossible that Phemlock will become CLIM-based and combine with Goatee
- CLOCC contains a package (elisp.lisp) that implements some part of elisp in CL.
- LiCE (repository on repo.or.cz) shows beginnings of another CL-based Emacs which can also run atop of Movitz.
At EmacsConf 2021, Fermin MF presented CEDAR as an Emacs developed in Common Lisp.
Description in repository: "CEDAR is an advance interactive development environment aiming to be Emacs compatible with all the features that come with it."
(Perceived) problems with the existing GNU Emacs
The primary problem with GNU Emacs is that Emacs Lisp is simply not great compared to Common Lisp.
- Slow GC
- Characters implemented as integers
- Dynamic scope everywhere (while conceding that it's essential to have in some places)
- Craig Finseth's book, The Craft of Text Editing, available in HTML form online. "Required reading about the implementation of Emacs-type text editors."
- If you're looking for a starting point for a new Emacs design you might like to take a look at Deuce, an Emacs like editor written in the Dylan programming language. Dylan has a CLOS style object model and it shouldn't be too difficult to port Deuce to Common Lisp. It separates GUI from editor code and has other interesting features. For details, see Scott Mckay's post (he is the author of Deuce). The source code to Deuce is available from https://github.com/dylan-lang/opendylan/tree/master/sources/deuce. Features:
- Lines are polymorphic. They can contain text, graphics, etc.
- There is the concept of 'Source containers' and 'source sections'. A buffer is composed of 'source sections' which can come from different contains. In a nutshell this means you can have a single buffer where different parts of that buffer come from different files. For example, Deuce uses this to display a single buffer containing all the methods for a generic function. Each method definition in the buffer comes from a different source file. Editing that section of the buffer edits the original file.
- The capability for graphics is included.
- A simple presentation framework is part of the design. Allowing 'live' objects in the editor.
- GUI presentation is separated from editor functionality allowing different GUI back ends to be used
- An interesting approach for a "CL-Emacs" would be for Emacs to be implemented as a set of processes, some being "display engines," others being loosely characterized as "buffer engines." Supposing Gnus had its own process, it might even block, and not slow down the other things going on. Erik Naggum had similar ideas.
- Kent Pitman describes some interesting features of Zmacs, the Lisp machine editor here.
- Distel ("distributed emacs lisp"), an extension of Emacs Lisp with the Erlang language's essential concurrency constructs, plus a (fully non-blocking) implementation of Erlang's inter-node distribution protocol. Also Ermacs, a fully concurrent Emacs written in Erlang (both core and extensions).
- The comp.lang.lisp thread that led to the creation of this page: https://groups.google.com/g/comp.lang.lisp/c/V7yiSIfLEis/m/sIhFE4M5yk4J
- There is a (mostly dormant) mailing list for discussing CL-Emacs. Details on the list are available at
- emacs paper
- Emacs Common Lisp - the other way around. CL implemented in Emacs Lisp.