Emacs Lisp Debate
Discussions focus on the role of Emacs Lisp (Elisp) in Emacs' architecture, its extensibility advantages, performance drawbacks, and proposals to improve or replace it with alternatives like Guile or other languages.
Activity Over Time
Top Contributors
Keywords
Sample Comments
You may be missing the point of Elisp. Elisp isn't an "extension language". It's the language Emacs is built with. When you run Emacs you're actually running a Lisp interpreter with a load of text editing features pre-loaded. When you eval some Lisp you're modifying the runtime, essentially live patching your editor in real time. So really any comparisons with Elisp are irrelevant unless you can do what it can do. Common Lisp and Scheme (Guile) are real contenders b
Well, certainly not the best choice. But of course, Emacs has a full Lisp implementation (ELisp) so certainly doable. The problem is not lack of turing-completeness or features, it is maintainability and performance. Apparently, the latter was not an issue, and the former has probably been solved by now by reimplementing the code in something more common.
Why is the core of Emacs still written in C? Is it just fear of trying to rewrite it from the ground up in Lisp, or is there something fundamental to the architecture that makes Lisp unsuitable?
I agree with you that replacing all of the eLisp with say JavaScript would be impractical because there are hundred thousands of lines of eLisp that would have to be replaced, but Emacs is never going to increase its appeal while requiring new users to learn its own, somewhat peculiar, extension language.Emacs out of the box is usable, but not as good as JetBrains tools or VS Code or Vim. Emacs is worth learning because it is an incredibly flexible editor construction kit that can be shaped
Agree with your high level point. Mine isn't that because it's written in e-lisp, emacs supports every other lisp. The fact that it's written in e-lisp makes it very extensible, and some standard things like C-x C-e to evaluate forms et al, which were originally developed for and are the standard for e-lisp, have been adopted for all other lisp modes as well. The very fact that the editor is written in a lisp makes it expose useful functionality this is useful in other lisp contex
There are 'bad things' in any programming language.Common Lisp is actually quite a bit more advanced out of the box than Emacs Lisp: lexical binding, excellent error handling, good support for compilation, extensive object-oriented features, it has multiple implementations with independet code bases, implementations with threading, ...CL has been used to develop Emacs editors already.But the thing is a non-starter. There are a few million lines of Emacs Lisp for a specific edi
Emacs is a Lisp interpreter. Expect even more interesting things to be built as performance is improved. I believe there is an effort under way to get Guile to process Elisp. Emacs could become the foundation for a lot more apps.
Much of Emacs is written in its own version of Lisp. There has been some effort to use Scheme, using GNU Guilehttps://www.emacswiki.org/emacs/GuileEmacsEmacs with a better Lisp option would be a big improvement. With a faster Lisp, perhaps less of Emacs would need to be written in C/Rust.
Is emacs no longer the go-to editing lisp?
What, you mean Emacs Lisp wasn't fast enough?