jwz@lucid.com (Jamie Zawinski) (11/30/90)
> Yes, I agree on most of this, although I don't quite know what you > mean with minor modes being "almost impossible" to implement > correctly? In Zmacs, modes automagically remember how to undo what they changed; this isn't true in GNU Emacs. If you have a minor mode that makes keybindings, it is responsible for remembering the previous value and restoring it. This can get arbitrarily hairy when more than one minor-mode is in effect. Consequently, there are almost no minor modes... > To redefine, rebuild... Yes! And no command hooks is a real loss as well - look at the contortions I had to go through to implement mail-abbrevs.el, posted on gnu.emacs.sources a month or two ago. It's not possible to change the behaviour of / implement something like auto-fill or abbrev-mode; those are implemented in C. I really don't understand why the C functions which call subrs don't indirect through the symbol table like good citizens. I doubt that the overhead for this is more than a few cycles, and even if it were expensive, I doubt that the functions which are callable from Lisp are used in time-critical code. > On the other hand Emacs is much faster than Zmacs most of the time, > even though it is byte-coded and has a lousy compiler. What makes you say this? The only time I have ever seen better performance out of GNU emacs is on io-bound operations, which is a function of the file system, not the editor. And anyway, we live in NFS Hell here, where auto-saves regularly take over a minute... Give me the somewhat slow but at least *consistent* Explorer file system any day! > Also, my 1.5MB BABYL file broke on the Explorer (it was suddenly 5MB, where > the extra space was epsilons, so Zmacs couldn't read it). Oops - that's a bug in Zmacs rmail. They read in the messages with a non-font-hacking stream, but write them out with a font-hacking one, so if you get mail with epsilons in it, the file gets munged. My mail-fonts stuff fixes this - spice.cs.cmu.edu:/usr/jwz/public/mail-font-patch.lisp. >> I'm not convinced: just because you can't have 12-bit characters in a file >> doesn't mean you can't have 12-bit input. If input was event-based instead >> of character based, then under X you could easily have seperate keybindings >> for left-shift-cokebottle and right-shift-cokebottle... > > OK, true, but do YOU want to hack Emacs to handle that? Well, actually, I think Emacs 19 does that already. At least, I'm pretty sure it's event-driven. >> ... but we're working on that ... > Tell us more, you DO work on a serious Lisp company nowadays... The latest project here at Lucid is a C/C++ development environment called Cadillac (in the sense of "fully loaded - automatic, comfortable, with three phones, a TV, and a wet-bar," not in the sense of "huge, gas-guzzling boat with fins." :-) Can you tell I don't like the name?) The basic idea is that the Cadillac kernel talks to a set of clients - an editor (GNU Emacs 19) a debugger (GDB), a linker, and a compiler. The user edits code, and hands it to Cadillac, which then passes it to the compiler, along with any dependancies which also need to be recompiled, and then the linker puts it all back together. This requires adding some smarts to the editor, debugger, and compiler, but not quite as much as you might think. The bottom line is that you get a Lispm-like environment for languages like C and C++ (which Cadillac is initially being developed for). It also makes use of hypertext links and "postit"-like annotations to your source code, which it stores in a persistent-object database. It also uses this mechanism to remember compilation dependancies - you don't need to edit a makefile any more, because Cadillac *knows* what depends on what after the first time it's all compiled. The development environment will contain such goodies as inspectors, call graphs, user-defined annotations pointing between different sections of code, the ability to elide sections of code or comments, etc. The debugger will be primarily source-level, in that the editor will be used for display. It will be possible to set breakpoints, examine locals, etc from within your source files. It will also be possible to (for example) make an annotation which replaces a piece of code with a debugging version that does more error checking; the original version and the debugging version will both be around in the persistent db, and it will be possible to switch between them at any time in the future. Plugging in a new compiler for a C-like language (Pascal, Ada, that sort of thing) will be fairly easy. All that needs to be done is, patch into the compiler, and teach the editor the syntax of the language. A major win is that the interface stays exactly the same. So the obvious thing of interest to this mailing list -- the group I am working in is prototyping a Lisp backend for Cadillac, which would mean a better-than-Lispm environment for Lisp on conventional hardware. I say "prototyping" because doing this for Lisp is trickier than for other languages. Cadillac was designed to be easy to interface to batch-mode languages like C++; the same kind of environment (from the user's point of view) is traditionally implemented in a very different way for Lisp. There are a lot of things you get for free with Lisp that need to be done in more primitive ways to make it work with batch-mode languages. It's going to be more work to interface it to Lisp than it would be to interface it to another C-like language, so there's a chance that it won't fly. (Kind of ironic, isn't it? :-)) A Lisp interface to Cadillac could possibly have another win, in that it could be used concurrently with the C interface -- so if your Lisp program made foreign calls to C code, the same commands would let you see backtraces, look at locals, etc., regardless of which side of the C/Lisp wall the flow of control happened to be on. (Well, maybe...) So that's what I'm up to. What's going on out there? -- Jamie PS: Please do not take what I said here as an official statement from Lucid - I may have gotten something wrong, because I'm not intimately familiar with the C side of Cadillac yet, and I have only a superficial understanding of the marketing plan. I'm just trying to give a rough picture from my side of the world.