The Emacs Problem (2005) | Hacker News Reader

The Emacs Problem (2005)

sites.google.com

14 pointspmoriarty14 comments

This is interesting -- I've seen many references and discussions of this, but this is the original that they were talking about. Thanks for the link.

So, stupid question:

Given that [1] one of the problems of moving Emacs to Common Lisp is that RMS & the FSF wouldn't cooperate

and

[2] the difficulty with this led Lucid to fork Emacs into XEmacs, which is still out there and updated in the SXMacs fork (http://www.sxemacs.org/)

then

[3] How about porting XEmacs or SXEmacs to CL instead?

GNU Emacs is the only active Emacs. Resurrecting one of those old forks like xemacs isn't really an option. Also replacing Elisp with CL isn't a good idea. There's very little actual reward on that investment.

See https://emacsconf.org/2019/talks/26/ (you can skim through the slides to save time)

People have different ideas but I'd like to emphasize the good work being done on GNU Emacs right now. Also lots of new efforts such as Remacs. But there's no reason to try to rewrite emacs in Common Lisp or GNU Guile or whatever.

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.

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.

> 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.

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

why would that be the ideal?

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

Closure CL’s editor is based on Hemlock — which is essentially a Common Lisp emacs.

Needs a [2005] (I was a bit puzzled by the dated XML enthusiasm)

If you read deeper you'll see he's actually not enthusiastic about XML, but only about tree-structured data, and is well aware of the drawbacks of XML, which is why he's actually advocating sexp's.

Also explains the lack of references to (currently) obvious alternatives like JSON or YAML.

XML, JSON, and YAML are all alternatives to s-expressions. And s-expressions were invented first.

Added. Thanks!

Reply on news.ycombinator.com