rustcat@csli.STANFORD.EDU (Vallury Prabhakar) (02/23/88)
The way I normally work in the Lisp interpreter, is to fire up Gnuemacs then open up a sub-window to set up an inferior shell to run Lisp in. For some strange reason, this doesn't always seem to work. Sometimes it works just fine, and other times it just hangs. All the interpreter seems to be able to recognize is when I type an invalid control character like ^C. Has this happened to anyone else? Could it be a bug in any of the above or something? This is rather frustrating, because I'd like to save the output of the Lisp-interpreter buffer into a file, and if Emacs keeps choking everytime I call up lisp, then I obviously can't do that. I'd appreciate any advice/suggestions that the gurus of netland might have in this matter. Here are the details: Lisp: Both KCL and Lucid produce the same results. I use only Common Lisp Machine: Sun/3/160. OS: 4.2BSD Emacs: (GNUEmacs) Version 18.50.1 Thank you. -- Vallury Prabhakar -- rustcat@cnc-sun.stanford.edu
helman@isl.Stanford.EDU (Jim Helman) (02/23/88)
In article <2492@csli.STANFORD.EDU> rustcat@russell.stanford.edu (Vallury Prabhakar) writes: >The way I normally work in the Lisp interpreter, is to fire up Gnuemacs >then open up a sub-window to set up an inferior shell to run Lisp in. >For some strange reason, this doesn't always seem to work. Sometimes >it works just fine, and other times it just hangs. All the interpreter >seems to be able to recognize is when I type an invalid control character >like ^C. > >Emacs: (GNUEmacs) Version 18.50.1 It appears that in release 18.50, lisp-mode.el was modified but shell.el wasn't changed to make it compatible. It may not be the same problem, since inferior lisps weren't working at all for me. I'm no emacs lisp hacker, but after changing line 390 of shell.el from: (lisp-mode-variables) to: (lisp-mode-variables nil) it seems to work OK. You'll also need to byte-compile the new shell.el or explicitly load it, otherwise you'll still be loading the old shell.elc file. Jim Helman (jim@thrush.stanford.edu) Department of Applied Physics Stanford University
weening@Gang-of-Four.Stanford.EDU (Joe Weening) (02/23/88)
Jim Helman's patch will work; or you can change the argument list of
the function "lisp-mode-variables" in lisp-mode.el from (lisp-syntax)
to (&optional lisp-syntax), to handle any calls that haven't been
updated.
--
Joe Weening Internet: JSW@SAIL.Stanford.EDU
Computer Science Dept. BITNET: JSW%SAIL.Stanford.EDU@Stanford
Stanford University UUCP: {decwrl,uunet}!SAIL.Stanford.EDU!JSWlrs@esl.UUCP (Lynn Slater) (02/24/88)
Posting-Front-End: GNU Emacs 18.44.12 of Mon Nov 16 1987 on esl (berkeley-unix) > The way I normally work in the Lisp interpreter, is to fire up Gnuemacs > then open up a sub-window to set up an inferior shell to run Lisp in. Try the "run-lisp" command. This fires up a special form of a subshell and allows expressions to be taken from other buffers. If you do alot of lisp, I am working on an enhanced "fancy-lisp" mode that is targeted at Lucid Lisp on a Sun. Features include: Better display of the expressions sent Automatic switching of packages to match changes of buffers Lisp control commands to abort break loops, scroll the lisp window, etc. Different ways to send the previous fcn, next fcn, current fcn, etc. I will gladly ship these changes to those who want to take a chance. I will submit them to the info-gnu-emacs folks when the changes are ready for general distribution. lrs@esl.COM
lou@bearcat.rutgers.edu (Lou Steinberg) (02/25/88)
I believe there used to be a bug in gnuemacs such that if you tried to
dump too much at once to a subjob, things could hang/crash/whatever.
This typically happened if you tried to send a defun to lisp with the
lisp-send-defun command, if the defun was more than a few lines long.
But I thought that this had been fixed???
--
Lou Steinberg
uucp: {pretty much any major site}!rutgers!aramis.rutgers.edu!lou
arpa: lou@aramis.rutgers.edu