Luke Gorrie's other self luke@bluetail.com writes in c.l.l:
marcelin7@yahoo.com (Nelson Marcelino) writes:
Hi all,
is there a way to reset lisp without having to exit from SLIME?
The undocumented way that I do it is to kill the *inferior-lisp* buffer (i.e. the lisp process) and then do `M-x slime' again. Alternatively you could do ,quit in the REPL, but that'll wipe out your old REPL history.
I've been meaning to ask about this for some time: why is ,sayoonara so eager to remove all traces of lisp activity?
Andras
Andras Simon andras@renyi.hu writes:
I've been meaning to ask about this for some time: why is ,sayoonara so eager to remove all traces of lisp activity?
because it's supposed to be a "i'm done with my lisp work so go away" command. if all you want to do is kill the underlying lisp you have (swank-backend:quit-lisp).
if you want to just restart the lisp without mesing with the repl buffers:
(defun slime-restart-lisp-image () (interactive) (when (slime-connected-p) (dolist (buf (buffer-list)) (when (or (string= (buffer-name buf) slime-event-buffer-name) (string-match "^\*inferior-lisp*" (buffer-name buf))) (kill-buffer buf)))) (call-interactively 'slime))
how often do people actually do this?
Marco Baringer mb@bese.it writes:
how often do people actually do this?
A couple of months ago, I was doing it several times a day. SLIME and CLISP would fall out of step. This would happen if CLISP was taking a long time to execute a form, or if I had written an infinite loop, and SLIME was unable to interrupt CLISP.
I've found that running CLISP as a separate process (started from a shell outside of XEmacs) helped correct these problems.
On Thu, 1 Jul 2004, Marco Baringer wrote:
Andras Simon andras@renyi.hu writes:
I've been meaning to ask about this for some time: why is ,sayoonara so eager to remove all traces of lisp activity?
because it's supposed to be a "i'm done with my lisp work so go away" command. if all you want to do is kill the underlying lisp you have (swank-backend:quit-lisp).
There are two common scenarios (at least for me):
(1) The Lisp image is fine, I just want to restart slime because I messed it up somehow. (2) I want to restart Lisp, to start from a clean state. But I'd like to keep input history.
For (1), there's always slime-disconnect and then slime, although something like ,restart-slime wuld be slightly more convenient. For (2), what you write:
if you want to just restart the lisp without mesing with the repl buffers:
(defun slime-restart-lisp-image () (interactive) (when (slime-connected-p) (dolist (buf (buffer-list)) (when (or (string= (buffer-name buf) slime-event-buffer-name) (string-match "^\*inferior-lisp*" (buffer-name buf))) (kill-buffer buf)))) (call-interactively 'slime))
works very nicely (thanks!). I think it's also worth a shortcut. How about ,restart-lisp?
how often do people actually do this?
More often than I'd like to :-(
Andras
Marco Baringer writes:
Andras Simon andras@renyi.hu writes:
I've been meaning to ask about this for some time: why is ,sayoonara so eager to remove all traces of lisp activity?
because it's supposed to be a "i'm done with my lisp work so go away" command. if all you want to do is kill the underlying lisp you have (swank-backend:quit-lisp).
if you want to just restart the lisp without mesing with the repl buffers:
(defun slime-restart-lisp-image () (interactive) (when (slime-connected-p) (dolist (buf (buffer-list)) (when (or (string= (buffer-name buf) slime-event-buffer-name) (string-match "^\*inferior-lisp*" (buffer-name buf))) (kill-buffer buf)))) (call-interactively 'slime))
how often do people actually do this?
Often enough. When debugging some programs or compilation or isntallation procedure, you need to restart with a clean state, but it's handy to keep the history in the buffer.
And conversely, I have some images running for a long time, where it's usefull to clean the buffer from time to time to have a clearer view of it. For example, when I dump a big backtrace, I like to clean everything from the top of the buffer down to the start of the backtrace to avoid puzzling over a previous backtrace. (Perhaps I should use narrow-to-region/widden, but I like to give work to the garbage collectors).
-
Andras Simon -
Marco Baringer -
Pascal J.Bourguignon -
Steven E. Harris