From ... Path: archiver1.google.com!news1.google.com!newsfeed.stanford.edu!canoe.uoregon.edu!arclight.uoregon.edu!newsfeed.mathworks.com!news.tele.dk!news.tele.dk!small.news.tele.dk!newsfeed1.ulv.nextra.no!nextra.com!uio.no!nntp.uio.no!ifi.uio.no!not-for-mail From: Erik Naggum Newsgroups: comp.lang.lisp Subject: Re: CLEmacs [was: I'm a Lisper, hear me roar...] Date: 08 Nov 2002 01:17:04 +0000 Organization: Naggum Software, Oslo, Norway Lines: 34 Message-ID: <3245707024453408@naggum.no> References: <3DC40755.3060803@nyc.rr.com> <3245251333120297@naggum.no> <3DC5561A.10507@nyc.rr.com> <3DC6C37F.3000404@nyc.rr.com> <465vddnnj.fsf@beta.franz.com> <3DC6F81A.2050609@nyc.rr.com> <7h3znso179r.fsf@pc150.maths.bris.ac.uk> <3DC7EADB.E7726B1F@nyc.rr.com> <87u1ivrh63.fsf@theasylum.dyndns.org> <87fzuer26h.fsf@theasylum.dyndns.org> <87smyds2ze.fsf@theasylum.dyndns.org> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: maud.ifi.uio.no 1036718225 16346 129.240.65.209 (8 Nov 2002 01:17:05 GMT) X-Complaints-To: abuse@ifi.uio.no NNTP-Posting-Date: 8 Nov 2002 01:17:05 GMT Mail-Copies-To: never User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Xref: archiver1.google.com comp.lang.lisp:45971 * Tim Lavoie | The "Emacs in CL" thread has come up before, hasn't it? I agree of | course, but I suspect that the reasons it hasn't happened are more | political than technical. I'm no Lisp expert, so I can't exactly | volunteer to just jump in and do it. It could be sweet though. An Emacs in Common Lisp would need a full reimplementation of Emacs Lisp and would need an enormous compatibility layer if it were to do anything differently internally. To succeed, it would also need to emulate both XEmacs and Emacs. Then it would need to track the development of both Emacsen. While it would make a lot of sense to reimplement the internals so that the MULEshit could be cleaned out and international support done right, Emacs is not just internals. What would /really/ make a difference to users would be if Emacs Lisp could be compiled to native code and not have to run through the byte-code interpreter. Some of the other things I have wanted for a Common Lisp Emacs is a user process that handles file system interaction instead of the Emacs doing it directly, a separation of the displayable area and the "buffer" so that less of the data would need to be transferred to the Emacs process and converted to the internal character set, which should be Unicode, and such that changes to the actual file would require minimal work, and many other things that are very hard to do in Emacs today that would change the way Emacs behaves and which would make it so much more usable for large files and being a "control center" now that most computer users command a number of computer, usually widely dispersed. Some of these ideas are strong enough that they could make a Common Lisp Emacs survive, but the amount of work to get there would simply be enormous. -- 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.