rustcat@russell.STANFORD.EDU (Vallury Prabhakar) (12/16/87)
Not that I can claim to be a Lisp whiz, but the present discussion has
made me curious.
The impression I've gotten so far, is that in order to program efficiently
in CL, one would need an editor that is custom-made for the language.
Smart pretty-printing, indentations, comments et all need to handled
efficiently by the editor. In other words, people seem to feel that
these utilities need to be "hard-wired" into the editor/system.
I can see how that would be a neat thing to do for Lisp machines like
the Explorers. (I personally do find that Explorers and especially the
editor to be quite fascinating). Since the sole environment that those
machines work in is Lisp itself, total compatibility between the editor
and the OS is desirable.
However, I find it strange that people should be knocking editors like
GNU/Gosling Emacs. Surely, these are not editors that were conceived
keeping Lisp in mind? At least, not primarily. The whole point of
these editors is their universality and flexibility. Under those
circumstances, isn't a bit unreasonable to expect the editor to be
able to figure out all sorts of nifty things for Lisp at the touch of
a key, and at the same time be able to handle other modes such as
electric-c-mode, etc? The best part about Emacs is that they are
so very open. Customizing the framework of these editors to suit the
individual programmer's taste (whether it's Lisp or C or whatever)
is eminently possible, and certainly less of a "hard-wiring" requirement
kludge.
Speaking from personal experience, I've done most of my Lisp on a Sun
using Gnu Emacs, and I'm very satisfied. Open up another window with
the lisp interpreter running in it, and set up your file to work in
Lisp mode, and that's all I've needed. Granted that the ZMACS editor
on the Explorers can probably do a better job with all sorts of nifty
little Lisp options, but can it switch into C/Tex mode when I want it to?
Afraid not.
Disclaimer: The above are my opinions only. You hear me?? MINE!
So spare me any flames.
-- Vallury
--
> (get life)
>>Error: LIFE has no global value
:C Try evaluating LIFE again
-> barmar@think.COM (Barry Margolin) (12/18/87)
In article <1168@russell.STANFORD.EDU> rustcat@russell.stanford.edu (Vallury Prabhakar) writes: >However, I find it strange that people should be knocking editors like >GNU/Gosling Emacs. Surely, these are not editors that were conceived >keeping Lisp in mind? Actually, since Stallman used to be a prolific Lisp Machine programmer when he was at MIT (he is responsible for a significant amount of the code in the Explorer and its Zmacs editor), and GNU Emacs is written largely in Lisp, there is a good deal of Lisp orientation in them. Flashing matching parentheses was invented to support Lisp programming; it just so happens that it is useful in other languages, but no one would have bothered doing it if it weren't for Lisp. > At least, not primarily. The whole point of >these editors is their universality and flexibility. Under those >circumstances, isn't a bit unreasonable to expect the editor to be >able to figure out all sorts of nifty things for Lisp at the touch of >a key, and at the same time be able to handle other modes such as >electric-c-mode, etc? What's so unreasonable about wanting it to do nifty things for Lisp when in Lisp Mode, nifty things for C in C Mode, etc.? > The best part about Emacs is that they are >so very open. Customizing the framework of these editors to suit the >individual programmer's taste (whether it's Lisp or C or whatever) >is eminently possible, and certainly less of a "hard-wiring" requirement >kludge. There's nothing hard-wired about the way the editors in Lisp Machines interface to the system. Compare two operations available in Zmacs on Symbolics Lisp Machines: in Lisp Mode one can ask the editor to print out the argument list of the function whose name was just typed, and in Text Mode one can ask to check the spelling of the current word. These are almost identical operations, it turns out: parse a token according to the current mode, and look it up in an appropriate database. Coincidentally, the database the first one looks it up in is the same database used by the runtime system when function calls occur, while the second database is only used by the spell-checking applications. But there is nothing hard-wired about either editor operation. The most you could say is that the Lisp Machine editor probably has more commands for dealing with Lisp code than it does for dealing with text, because Lisp Machines were designed to be super Lisp development environments. >Granted that the ZMACS editor >on the Explorers can probably do a better job with all sorts of nifty >little Lisp options, but can it switch into C/Tex mode when I want it to? >Afraid not. Well, I don't know about Zmacs on the Explorer, but Symbolics has implemented very advanced syntax-oriented editing for non-Lisp languages in Zmacs. In fact, from what I've heard (since I've never personally used any of their languages other than Lisp), they provide many features that they don't provide for Lisp. They maintain a complete parse tree of the program in parallel with editing (I presume it has some heuristics to deal with the fact that the buffer doesn't always represent a correct program), and have commands for inserting statement templates, in addition to most of the facilities that they provide for Lisp programming. The interfaces from Zmacs to the compilers are the same as those for Lisp, e.g. Control-Shift-C in C mode will compile the current C function. And I'll bet it blinks matching curly braces, parentheses and square brackets. Just because something is written in Lisp doesn't mean it's only good for Lisp (but you already knew that about GNU and Gosling Emacs). --- Barry Margolin Thinking Machines Corp. barmar@think.com seismo!think!barmar