No question, this would be a challenging project. 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. On Thursday, July 2, 2015 at 3:36:47 PM UTC-4, Greg Davidson wrote: > Is there interest in creating a Gnu Emacs Lisp Racket Language, along with > the underlying APIs (perhaps tied to DrRacket) sufficient to compile and run > Gnu Emacs Lisp extension packages? Is there prior or ongoing work for such a > project? > > 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) -- 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+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
