the Modernization of Emacs
in [Lisp]
|
From: Tom Lord on 12 Apr 2006 21:35 Christophe Rhodes wrote: > If Common Lisp is an improved lisp from your point of view, Not for the purpose of an Emacs on a non-lisp-machine platform. > can I > encourage you to look at the Climacs project? You did and I did. The notes in the "how to contribute" section about what is not of interest suggest we have very different goals. Thanks, though. Looks like a potentially fun project in its own right. -t
From: Tom Lord on 12 Apr 2006 21:37 Bill Atkins wrote: > Why do you use "yr" instead of "your" but write the rest of your posts > in totally coherent English? > > I have never seen anything so bizarre. I am sorry for you that you have led such a sheltered life. -t
From: Greg Menke on 12 Apr 2006 21:49 Edward Dodge <user(a)foo.bar> writes: > Greg Menke <gregm-xyzpdq3(a)toadmail.com> writes: > > > As far as OS X, the gui & mouse are just too tedious. I find it easier > > to use plain emacs -nw in multiple terminal windows and get on with the > > job at hand. My preference with Mac hardware is to put Linux on it and > > run Windowmaker. > > Why bother with Linux just to use an X11 manager? Install X11.app on OSX and > then install the X11-version of EMACS. Run OSX and an X-Window window-manager > (complete with all your X-based apps) at the same time. Its not the X11 I'm so interested in, its the non-bizarre suite of gnu stuff, easily configurable OS & daemons, etc.. OS X is extremely tedious to configure once you get beyond what the click-and-drool control panel gives you. For instance, try to get OS X to stop hostname'ing itself when it gets an address from an ISP. It wouldn't be so bad if OS X offered virtual terminals like Linux does- which I make a lot of use of. There are also some subtle fragility relating to OS bootup and ipfw, any custom firewall/gateway/nat configuration has to be hacked with great care. And last time I checked there is an almost complete lack of detailed OS config documentation which doesn't help. Gregm
From: Robert Strandh on 13 Apr 2006 00:57 I was not going to bring up Climacs, because it is not ready for prime time, but Christophe did, so now I feel I should comment. Ari Johnson <iamtheari(a)gmail.com> writes: > The problem I have with Climacs is that I can't use it. All my > machines are Macs except for Linux servers, so X11 applications (while > technically usable) are not useful to me. I wish that I had the CLIM > and Cocoa experience necessary to create an OSX CLIM, as that is > something I see as being an immensely useful project. Right. As you know, Climacs is a CLIM application and not an X11 application. Though you can argue that McCLIM is mostly an X11 application, so Climacs right now indirectly requires X11 as you have realized. However, I maintain that using CLIM as the interface substrate for Climacs was and is the right decision because it creates infrastructure that is useful elsewhere. We welcome more backends for McCLIM that will make Climacs and other CLIM applications useful on platforms that do not have X11, but as with most free software projects, we need help to do this. > The other problem that many people would have with adopting Climacs is > that it appears to the average user to be comparatively difficult to > install and run, when compared head-to-head against Emacs. Emacs is > well-tested on all platforms it runs on and Elisp is consistent across > them. While I agree with this in principle, it is hardly a fair comparison. Like I said, Climacs is not ready for prime time, and I don't know when it will be. Making it easy to install and run is just one of literally hundreds of little tedious issues that need to be addressed. I sure hope they will be addressed eventually, but it is not possible for a handful of part-time developers to do this alone. > Also, there is little danger that a piece of Elisp code will > step outside of Emacs to do something naughty; whereas, with a CL > editor, there is much more opportunity for a script to do something > outside the scope of the editor. This is danger but especially a major advantage. It allows much better integration with Common Lisp than can be had with an external editor. And Climacs was written primarily to be part of an IDE for CL. I would prefer to address this problem by making current CL implementations enforce the restrictions on the COMMON-LISP package that seem to be designed to avoid disasters as a result of bad application programs. Package locks are a start but not enough. > Furthermore, you would be best to > package a CL with the editor, since the capabilities of a given CL > change with each version. (Witness that Debian 'sarge' comes with > SBCL 0.8.16, which cannot run the Swank component of SLIME post-April > 19, 2005.) So you have a size issue - Emacs is big, but a CL is not a > tiny thing to be throwing around along with it. Personally, I rather hope that the capabilities of CL implementations will settle down so that we would not have to distribute CL with Climacs. If we had to distribute a CL with Climacs, this would defeat some of the purposes with Climacs, namely to be used with an IDE for your preferred CL implementation. > Do you have plans to address these issues? I could answer "of course", but in reality there are no plans to do anything whatsoever. All we have is a bunch of part-time developers (who sometimes get full-time jobs and quit developing Climacs) who do whatever they please, find interesting, and have time for. Personally, I think Climacs is a very interesting project, in that I think we have shown that a modern Emacs can be implemented with relatively little effort (I don't think we have spent even a single person-year on it yet, unless you count applications such as the Tabcode editor built as Climacs applications). We have a very nice (in my opinion) buffer protocol and several different implementations of it that can function together. We also have a much better infrastructure for syntax analysis of the buffer contents than Emacs does, and quite a decent CL syntax module to show that. For Common Lisp, our indentation code already does a better job than that of Emacs. Personally, I have no ambition for Climacs to ever do what Emacs currently does, for the simple reason that many of the existing Elisp applications such as dired, Gnus, VM, etc would be better implemented as CLIM applications, possibly with Climacs used when an editor is required. Rather, I see Climacs as part of a set of collaborating CL and CLIM applications to run in a single image, and with tight integration, allowing them to share data structures in core. I do think that Climacs is a great base for a modern Emacs implementation using a modern and great Lisp dialect. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. ---------------------------------------------------------------------
From: Robert Strandh on 13 Apr 2006 01:05
Ari Johnson <iamtheari(a)gmail.com> writes: > Bill Atkins <NOatkinwSPAM(a)rpi.edu> writes: > > > I'm not aware of any effort on Elisp's part to prevent code from doing > > damage to a machine. > > I was thinking more in terms of within the Lisp but outside of the > editor. I'm not well-versed in elisp, but it seems to me that it > would be easier to break the editor in CL than in elisp, given that at > least part of Emacs is not written in elisp and thus at least part of > it cannot be broken with elisp alone. I may be entirely wrong. I think you probably are :-) Seriously, the moment you decide to give your users the power to modify the behavior of the application with the power of a programming language like Lisp, you also make it possible for them to break it. This is a feature and not a bug. You would not want this to happen accidentally, of course, but I think it would be a serious mistake to try to prevent your users from breaking certain parts of the editor by making it impossible to adapt those parts to their own needs. -- Robert Strandh --------------------------------------------------------------------- Greenspun's Tenth Rule of Programming: any sufficiently complicated C or Fortran program contains an ad hoc informally-specified bug-ridden slow implementation of half of Common Lisp. --------------------------------------------------------------------- |