[pmoriarty]

There is good work done in GNU Emacs, but in other respects I have to disagree.

Having Emacs be "Lisp all the way down" is my ideal, and the ideal of many other Emacs users.

While rewriting the C portions of Emacs in Rust would be a step forward, because of its non-Lispy nature it would still fall far short of an Emacs fully written in Lisp or Scheme.

Ideally, Emacs would be fully written in and scripted in the same language, and that language would be a Lisp.

[twentydollars]

There's no such thing as "lisp all the way down" unless you're running a lisp machine. Common Lisp, e.g. SBCL, is written in C. So I'd say Emacs already is almost "Lisp all the way down" in any meaningful interpretation. Elisp is written in C, yes. And there are a few functions written in C for performance. What abstract benefit is worth completely replacing this with some other language that will inevitably be written in C anyway?

In the meantime, people are actually improving elisp, giving us things like the new async options and performance improvements. People like to hate on elisp because of some ugly syntax and some missing stuff that most mainstream programming languages have, but it's uniquely crafted for Emacs stuff and fills that role better than any other language.

[lispm]

> SBCL, is written in C

SBCL is written in C, a bit assembly and most of the code is written in Common Lisp. For example the compiler which generates native code for various processors is written in Common Lisp. A lot of code can be written from Common Lisp, which calls external OS routines via Foreign Function Calls. Thus there is not much C-based glue code needed.

In GNU Emacs the execution engine running the byte code is written C. The byte code compiler is written in Emacs Lisp.

[twentydollars]

So the ideal would be to have the execution engine written in elisp (or the elisp replacement)?

[lispm]

why would that be the ideal?

[twentydollars]

I guess I was asking pmoriarty. It's not my ideal. Just trying to understand their reasoning.