Path: utzoo!mnetor!uunet!husc6!think!barmar From: barmar@think.COM (Barry Margolin) Newsgroups: comp.lang.lisp Subject: Re: Lisp and editing Message-ID: <13902@think.UUCP> Date: 17 Dec 87 22:19:58 GMT References: <1168@russell.STANFORD.EDU> Sender: usenet@think.UUCP Reply-To: barmar@sauron.think.com.UUCP (Barry Margolin) Organization: Thinking Machines Corporation, Cambridge, MA Lines: 73 Keywords: Lisp, editors, systems, other languages, flame-less 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