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
->
From: Barry Margolin
Subject: Re: Lisp and editing
Date:
Message-ID: <13902@think.UUCP>
In article <····@russell.STANFORD.EDU> ·······@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.
······@think.com
seismo!think!barmar