Subject: Re: CLEmacs From: Erik Naggum <email@example.com> Date: 08 Nov 2002 07:42:19 +0000 Newsgroups: comp.lang.lisp Message-ID: <firstname.lastname@example.org> * Piers Cawley <email@example.com> | Serious question: Why? Because even now, package developers are seriously pissed off by the incompatibilities between Emacs and XEmacs. | Initially one could do ports of 'important' elisp modules to the new | language by hand, bearing in mind that it's generally better to port by | writing a pile of support functions rather than by changing the code | itself. Emacs Lisp is the extension language built on top of the C substrate, which exports a large number of C-level decisions to Emacs Lisp. In order for such a project to get off the ground at all, those packages that people are quite used to would have to work in the new Emacs. This means presenting a compatibility layer that is quite extensive. Take my word for it, if you want to change the substrate language, you will notice that the substrate language of Emacs really is C. This is not something people will believe right away, since it superficially looks very much like a Lisp application. | It's still a *huge* pile of work of course, but by doing it incrementally | and worrying about the elisp interface later, you at least get yourself a | working, useful editor a good deal earlier in your development cycle. Well, I went there, spent a few months hacking on clemacs (and even got the domain name), and discovered that it would take many years, for no real practical improvements until /way/ into the project. | Not that I actually have the skills to put my money where my mouth is | here. Feel free to dismiss me as a crank, I was just curious as to | whether this sort of incremental approach had been considered. All approaches you can think have been considered... -- Erik Naggum, Oslo, Norway Act from reason, and failure makes you rethink and study harder. Act from faith, and failure makes you blame someone and push harder.