For some years there has been an attempt to port Gnu Emacs to run under Guile Scheme. A big stumbling block is the vast amount of extensions written in Emacs Lisp and continuing development thereof. Racket seems to be a *much* better platform for such a project than Guile, don't you think?
_Greg (a long-time ambivalent Emacs user tired of Emacs Lisp)
Thanks Matthias ... there's nothing on Tony's projects pages so I've sent him a message. _Greg
--
You received this message because you are subscribed to the Google Groups "Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to racket-users...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
If a Free Software reimplementation was fully compatible with Gnu Emacs at the Emacs Lisp level, it could also provide a superior architecture underneath for new code written nicer Racket languages. Unless and until the new editor wins over most of the users of the existing Gnu Emacs, it is critical to maintain backwards compatibility for traditional Emacs Lisp and the traditional API.
Implementing Emacs Lisp presents a possibly interesting challenge to Racket's language framework. It may help that Emacs Lisp now supports lexical binding clearly signalled on a per-module basis.
_Greg
Do a clean room fresh implementation or provide full Emacs Lisp compatibility? Would it make sense to consider doing a strict subset of Emacs Lisp, with sufficiently flexibility to allow popular extensions run while leaving others behind?
Common Lisp tried a clean room approach a long time but unfortunately it ended up languishing. They had some very interesting ideas based on an interface framework that I understand were heavily inspired by Geneva Symbolics Dynamic Windows.
Their attempt, Climacs https://common-lisp.net/project/climacs/ which was based on https://en.wikipedia.org/wiki/Common_Lisp_Interface_Manager
From what I've seen so far, it appears they generalized the buffer idea to handle arbitrary data, both text and graphics in a more systematic way. They had an example of browsing a file system with all the file icons and clickable expandable nodes right within the buffers.
Worth it checking to see if their ideas can be reused.