[slime-devel] Evaluate forms from within Lisp buffers and displaying the result in the REPL
Hi,
I'm a bit used to the behavior of MCL when it comes to Lisp buffers and listeners. Maybe SLIME developers know how to achieve a similar behavior or would like to provide something similar.
MCL allowed multiple Lisp text editor windows and listener windows. If there are multiple listeners one is the front most.
If the cursor is behind a Lisp form in a Lisp editor window, one can press Enter (or control-return) and the form will be enqueued into the REPL of the front most listener. Doing this in a listener, the form will be displayed at the prompt and enqueued in the listener's REPL. Pressing Enter only has the effect that the form and the result is shown in the listener. In the Editor window, nothing happens (no cursor moved, no character entered, no window focus changed).
The listener REPL gets the forms from its queue and displays the form and the result at the end of the current buffer. This way you get interaction histories in the listener.
Currently SLIME lets me evaluate a form in a text buffer and the form gets printed into the listener and the result gets printed in the mini-buffer. I can see then in the listener the history of evaluated forms, but not the history of results. Additionally the form will be printed with additional characters before and after.
SLIME displays several forms evaluated from a text buffer in the REPL like this:
;;;; (+ 1 2) ... ;;;; (+ 1 2) ... ;;;; (+ 1 2) ...
The normal REPL interaction display would be like:
CL-USER> (+ 1 2) 3 CL-USER> (+ 1 2) 3 CL-USER> (+ 1 2) 3
Both ways look different. Why not use the latter for both interactions?
Useful is then also a command to rotate between the various listeners (next, previous) and Lisp buffers (next, previous).
Advantages I see for MCL: * With MCL you get the same REPL listener display if you evaluate forms from the Lisp editor buffer (via RETURN) or if you use the REPL in the listener. * Using the enter key (vs. Return) to evaluate code in the editor gets rid of one complex keystroke. * One gets reusable interaction histories in the listener where form and result are displayed together.
Is SLIME already providing something similar? Would others find this way of interaction between Lisp buffers and a REPL buffer useful?
Regards,
Rainer Joswig
As another former MCLer, I would love to have this feature back. It was really nice!
-- Gary Warren King, metabang.com Cell: (413) 885 9127 Fax: (206) 338-4052 gwkkwg on Skype * garethsan on AIM
Hi Rainer,
On 4/17/07, Rainer Joswig joswig@lisp.de wrote:
I'm a bit used to the behavior of MCL when it comes to Lisp buffers and listeners. Maybe SLIME developers know how to achieve a similar behavior or would like to provide something similar.
MCL allowed multiple Lisp text editor windows and listener windows. If there are multiple listeners one is the front most.
SLIME does allow you to have multiple REPL windows. When you do "M-x slime" multiple times, it will ask you whether you want to create an additional repl.
If the cursor is behind a Lisp form in a Lisp editor window, one can press Enter (or control-return) and the form will be enqueued into the REPL of the front most listener. Doing this in a listener, the form will be displayed at the prompt and enqueued in the listener's REPL. Pressing Enter only has the effect that the form and the result is shown in the listener. In the Editor window, nothing happens (no cursor moved, no character entered, no window focus changed).
The listener REPL gets the forms from its queue and displays the form and the result at the end of the current buffer. This way you get interaction histories in the listener.
Currently SLIME lets me evaluate a form in a text buffer and the form gets printed into the listener and the result gets printed in the mini-buffer. I can see then in the listener the history of evaluated forms, but not the history of results. Additionally the form will be printed with additional characters before and after.
SLIME displays several forms evaluated from a text buffer in the REPL like this:
;;;; (+ 1 2) ... ;;;; (+ 1 2) ... ;;;; (+ 1 2) ...
The normal REPL interaction display would be like:
CL-USER> (+ 1 2) 3 CL-USER> (+ 1 2) 3 CL-USER> (+ 1 2) 3
Both ways look different. Why not use the latter for both interactions?
Useful is then also a command to rotate between the various listeners (next, previous) and Lisp buffers (next, previous).
Advantages I see for MCL:
- With MCL you get the same REPL listener display if you evaluate forms from
the Lisp editor buffer (via RETURN) or if you use the REPL in the listener.
- Using the enter key (vs. Return) to evaluate code in the editor gets rid of one complex keystroke.
- One gets reusable interaction histories in the listener where form and result are displayed together.
Is SLIME already providing something similar? Would others find this way of interaction between Lisp buffers and a REPL buffer useful?
I don't think SLIME provides this as a standard feature. However, I have a function that I use to do this. It sends to the repl buffer either the current highlighted region, or the sexp that is on/before the point, or the sexp that is on/after the point, or the top-level sexp (if the point is not on/before/after a paren). With a prefix arg, it will also press "Enter" in the repl so you don't have to press enter yourself. I frequently use the function when I'm doing presentations and want to step through code in a listener for the audience.
Here's the code with a sample binding of F9 (so use either F9 or C-u F9):
(defun slime-send-dwim (arg) "Send the appropriate forms to CL to be evaluated." (interactive "P") (save-excursion (cond ;;Region selected - evaluate region ((not (equal mark-active nil)) (copy-region-as-kill-nomark (mark) (point))) ;; At/before sexp - evaluate next sexp ((or (looking-at "\s(") (save-excursion (forward-char 1) (looking-at "\s("))) (forward-list 1) (let ((end (point)) (beg (save-excursion (backward-list 1) (point)))) (copy-region-as-kill-nomark beg end))) ;; At/after sexp - evaluate last sexp ((or (looking-at "\s)") (save-excursion (backward-char 1) (looking-at "\s)"))) (if (looking-at "\s)") (forward-char 1)) (let ((end (point)) (beg (save-excursion (backward-list 1) (point)))) (copy-region-as-kill-nomark beg end))) ;; Default - evaluate enclosing top-level sexp (t (progn (while (ignore-errors (progn (backward-up-list) t))) (forward-list 1) (let ((end (point)) (beg (save-excursion (backward-list 1) (point)))) (copy-region-as-kill-nomark beg end))))) (set-buffer (slime-output-buffer)) (unless (eq (current-buffer) (window-buffer)) (pop-to-buffer (current-buffer) t)) (goto-char (point-max)) (yank) (if arg (progn (slime-repl-return) (other-window 1)))))
(define-key lisp-mode-map [f9] 'slime-send-dwim)
-- Bill Clementson
"Bill Clementson" billclem@gmail.com writes:
Hi Rainer,
On 4/17/07, Rainer Joswig joswig@lisp.de wrote:
I'm a bit used to the behavior of MCL when it comes to Lisp buffers and listeners. Maybe SLIME developers know how to achieve a similar behavior or would like to provide something similar.
MCL allowed multiple Lisp text editor windows and listener windows. If there are multiple listeners one is the front most.
SLIME does allow you to have multiple REPL windows. When you do "M-x slime" multiple times, it will ask you whether you want to create an additional repl.
are you sure? i tried this today and multiple M-x slime will start multiple swank-servers in the lisp but you still only get one repl buffer (this looks a lot like a bug).
SLIME displays several forms evaluated from a text buffer in the REPL like this:
;;;; (+ 1 2) ... ;;;; (+ 1 2) ... ;;;; (+ 1 2) ...
The normal REPL interaction display would be like:
CL-USER> (+ 1 2) 3 CL-USER> (+ 1 2) 3 CL-USER> (+ 1 2) 3
Both ways look different. Why not use the latter for both interactions?
this would only make sense, imho, if evaling code in the buffers respected the repl's *package*, *readtable*, etc. and updated *, **, ***, +, ++, etc.
is this what you're suggesting? i'm not sure i like it, it's nice to have some code in the repl which tests a function and have recompiling that function not upset the state of the repl. however if we allowed multiple, independant, repls this wouldn't be such a problem.
Useful is then also a command to rotate between the various listeners (next, previous) and Lisp buffers (next, previous).
Advantages I see for MCL:
- With MCL you get the same REPL listener display if you evaluate forms from
the Lisp editor buffer (via RETURN) or if you use the REPL in the listener.
- Using the enter key (vs. Return) to evaluate code in the editor gets rid of one complex keystroke.
what's the complex key stroke you want t get rid of?
- One gets reusable interaction histories in the listener where form and result are displayed together.
do you use this with normal functions as well or just snippets of test code? if so how do you avoid being overwhelemed with slightly similar but different function/class/whatever definitions interspersed with 'interesting' code and results?
Is SLIME already providing something similar? Would others find this way of interaction between Lisp buffers and a REPL buffer useful?
I don't think SLIME provides this as a standard feature. However, I have a function that I use to do this. It sends to the repl buffer either the current highlighted region, or the sexp that is on/before the point, or the sexp that is on/after the point, or the top-level sexp (if the point is not on/before/after a paren). With a prefix arg, it will also press "Enter" in the repl so you don't have to press enter yourself. I frequently use the function when I'm doing presentations and want to step through code in a listener for the audience.
Here's the code with a sample binding of F9 (so use either F9 or C-u F9):
did bill's code do something similar to what you wanted?
In article m2hcrb6xhw.fsf@bese.it, Marco Baringer mb@bese.it wrote:
"Bill Clementson" billclem@gmail.com writes:
Hi Rainer,
On 4/17/07, Rainer Joswig joswig@lisp.de wrote:
I'm a bit used to the behavior of MCL when it comes to Lisp buffers and listeners. Maybe SLIME developers know how to achieve a similar behavior or would like to provide something similar.
MCL allowed multiple Lisp text editor windows and listener windows. If there are multiple listeners one is the front most.
SLIME does allow you to have multiple REPL windows. When you do "M-x slime" multiple times, it will ask you whether you want to create an additional repl.
are you sure? i tried this today and multiple M-x slime will start multiple swank-servers in the lisp but you still only get one repl buffer (this looks a lot like a bug).
SLIME displays several forms evaluated from a text buffer in the REPL like this:
;;;; (+ 1 2) ... ;;;; (+ 1 2) ... ;;;; (+ 1 2) ...
The normal REPL interaction display would be like:
CL-USER> (+ 1 2) 3 CL-USER> (+ 1 2) 3 CL-USER> (+ 1 2) 3
Both ways look different. Why not use the latter for both interactions?
this would only make sense, imho, if evaling code in the buffers respected the repl's *package*, *readtable*, etc. and updated *, **, ***, +, ++, etc.
I reread a bit the MCL manual.
The command for evaluation is bound to Enter. You can press Enter when you are right after or before a form in the Lisp editor. If a region is marked, use the region.
MCL usually reads the form using the package of the Lisp buffer. If there is no package set, it uses the value of cl:*package* .
I guess it uses the readtable of the Listener.
The form is enqueued in the Listener, which also means that the execution will run in the process thread of the listener. In MCL you can let the listener work on a few enqueued forms, and continue to use the Lisp buffer (move around, edit, ...).
Normally the form is not printed, but the result will be printed in the Listener.
The variables *, **, ***, etc. are updated.
The standard output stream is also set to the listener and any output the code prints is by default going to the listener.
The standard-input is also set to the listener.
After the listener has finished executing the enqueued forms, the listener's mini-buffer shows 'Done' as a message.
There is a lot of trickery involved in MCL's editor code.
But the basic idea is for simple execution of code is:
* read the code from the editor using its package * execute the code in the environment of the top-most listener using its setting, streams, ...
Some Commands in MCL:
Enter Eval or Compile Current Sexp C-x C-c Eval or Compile Top Level Sexp C-x C-e Eval Current Sexp C-M Macro Expand (result printed to the top-level listener) C-x C-r Read Current Sexp (the result will be pretty printed in the top-level listener)
For me using a listener as output buffer makes a lot of sense.
But MCL is multithreaded. Maybe this is difficult to replicate with Emacs? Maybe some simplified version would be useful.
is this what you're suggesting? i'm not sure i like it, it's nice to have some code in the repl which tests a function and have recompiling that function not upset the state of the repl. however if we allowed multiple, independant, repls this wouldn't be such a problem.
Useful is then also a command to rotate between the various listeners (next, previous) and Lisp buffers (next, previous).
Advantages I see for MCL:
- With MCL you get the same REPL listener display if you evaluate forms from
the Lisp editor buffer (via RETURN) or if you use the REPL in the listener.
- Using the enter key (vs. Return) to evaluate code in the editor gets rid of one complex keystroke.
what's the complex key stroke you want t get rid of?
C-x C-e
Opinion: In a Lisp environment there should be direct keys for basic Lisp interaction commands. Entering code to the REPL for execution would be such a basic interaction. Others are indenting (Tab), entering a break loop, aborting, completion, ...
- One gets reusable interaction histories in the listener where form and result are displayed together.
do you use this with normal functions as well or just snippets of test code? if so how do you avoid being overwhelemed with slightly similar but different function/class/whatever definitions interspersed with 'interesting' code and results?
See above, I think normally (IIRC, one could set this with a variable) only the result gets printed in the Listener.
In the listener it worked a bit different. There the form is being copied to the current prompt. Typically I would scroll back in the history, place my cursor to some Lisp expression and press enter. Then the form gets copied to the prompt, gets executed and the result gets printed.
Is SLIME already providing something similar? Would others find this way of interaction between Lisp buffers and a REPL buffer useful?
I don't think SLIME provides this as a standard feature. However, I have a function that I use to do this. It sends to the repl buffer either the current highlighted region, or the sexp that is on/before the point, or the sexp that is on/after the point, or the top-level sexp (if the point is not on/before/after a paren). With a prefix arg, it will also press "Enter" in the repl so you don't have to press enter yourself. I frequently use the function when I'm doing presentations and want to step through code in a listener for the audience.
Here's the code with a sample binding of F9 (so use either F9 or C-u F9):
did bill's code do something similar to what you wanted?
I have to check that. I'll report later.
Marco Baringer wrote:
this would only make sense, imho, if evaling code in the buffers respected the repl's *package*, *readtable*, etc. and updated *, **, ***, +, ++, etc.
is this what you're suggesting? i'm not sure i like it, it's nice to have some code in the repl which tests a function and have recompiling that function not upset the state of the repl. however if we allowed multiple, independant, repls this wouldn't be such a problem.
I don't know Rainer wants, but I've often enough hoped that C-x C-e updated * &co. Because of that I now more often use C-c I then C-x C-e...
C-c C-c should of course not touch * &co.
Cheers,
-- Nikodemus
Hi Nikodemus,
On 4/20/07, Nikodemus Siivola nikodemus@random-state.net wrote:
Marco Baringer wrote:
this would only make sense, imho, if evaling code in the buffers respected the repl's *package*, *readtable*, etc. and updated *, **, ***, +, ++, etc.
is this what you're suggesting? i'm not sure i like it, it's nice to have some code in the repl which tests a function and have recompiling that function not upset the state of the repl. however if we allowed multiple, independant, repls this wouldn't be such a problem.
I don't know Rainer wants, but I've often enough hoped that C-x C-e updated * &co. Because of that I now more often use C-c I then C-x C-e...
What do you have "C-c |" bound to? It must be a custom binding that you've setup as I don't think it is a standard SLIME binding.
-- Bill Clementson
Bill Clementson wrote:
What do you have "C-c |" bound to? It must be a custom binding that you've setup as I don't think it is a standard SLIME binding.
C-c I, not C-c |.
Slime-inspect, default binding. The nice thing it that it evaluates the current form. What most often use * for is to inspect the result in more detail, and C-c I does that for me.
Cheers,
-- Nikodemus
On 4/23/07, Nikodemus Siivola nikodemus@random-state.net wrote:
Bill Clementson wrote:
What do you have "C-c |" bound to? It must be a custom binding that you've setup as I don't think it is a standard SLIME binding.
C-c I, not C-c |.
Slime-inspect, default binding. The nice thing it that it evaluates the current form. What most often use * for is to inspect the result in more detail, and C-c I does that for me.
Ah, ok. I read the "I" as "|" and thought that you had set up a custom binding to "pipe" output to the repl.
Cheers, Bill
Hi Marco,
On 4/20/07, Marco Baringer mb@bese.it wrote:
"Bill Clementson" billclem@gmail.com writes:
Hi Rainer,
On 4/17/07, Rainer Joswig joswig@lisp.de wrote:
I'm a bit used to the behavior of MCL when it comes to Lisp buffers and listeners. Maybe SLIME developers know how to achieve a similar behavior or would like to provide something similar.
MCL allowed multiple Lisp text editor windows and listener windows. If there are multiple listeners one is the front most.
SLIME does allow you to have multiple REPL windows. When you do "M-x slime" multiple times, it will ask you whether you want to create an additional repl.
are you sure? i tried this today and multiple M-x slime will start multiple swank-servers in the lisp but you still only get one repl buffer (this looks a lot like a bug).
Yes, I'm sure. Well, at least I'm sure it does one specific thing (which may not be what you think Rainer wants nor what he actually does want ;-) ). I don't usually use multiple repl's, so I'm not sure I understand the specific use case that Rainer wants to address. As I see it, there may be 3 different types of "new" repl's that one could want to have (which, depending on your specific use case may or may not be what is required):
#1: You want to "play around" with some ideas but don't want to "muck up" your existing lisp environment and repl. In that case, you probably want to start up a new lisp instance and test things in a completely independent repl. When I do "M-x slime" multiple times (and say "n" to the "Create an additional *inferior-lisp*?" prompt), that is exactly what I get - multiple lisp instances with a separate repl for each one. I can use "C-c C-x c" to switch between them so I can do my "mucking around" in the one repl and do the "real stuff" in the other repl ("C-c C-x c" also controls which repl is "active" when you're in a lisp buffer compiling/evaluating/etc code).
#2: You want to have multiple repl's on the same lisp instance (with each repl sharing the repl history and */**/***/etc values). This is useful if you want to use one repl for a demo but want to be able to enter other commands in another repl to set up or modify an environment for the demo. There are probably other use cases for this; however, this is what I normally use #2 for. Again (as with #1), I can use "C-c C-x c" to switch between the repl's so I have control over which one is "active". Although SLIME does not provide any standard function for automatically creating multiple repl's, it is easy enough to do if you are using a lisp with threads. In your existing SLIME repl, you can just enter "(swank::create-server :port some-port)" and then in emacs do a "M-x slime-connect" and specify the host & port. If you do this a lot, you could automate it with something like the following:
(defun slime-new-repl () "Create additional REPL for the current Lisp connection." (interactive) (if (slime-current-connection) (let ((port (slime-connection-port (slime-connection)))) (slime-eval `(swank::create-server :port ,port)) (slime-connect slime-lisp-host port)) (error "Not connected")))
and just do "M-x slime-new-repl" whenever you wanted a new repl. As you can see from the above function, although you can specify any port, you can also just reuse the existing port for the separate repl, so it's easy enough to do when you're ssh'ing to a remote machine too.
#3: You want to have multiple repl's on the same lisp instance (with each repl having it's own repl history and */**/***/etc values). I thought that it was possible to do this at one time with SLIME; however, I just had a play and I don't think there is any way that you can currently do this in SLIME.
I thought Rainer was after #1 when I initially replied. If he is after #1 or #2, SLIME currently supports these types of multiple repl's. If he was looking for #3, I don't think that is currently supported. Maybe Rainer could indicate what specific use case he is trying to address with multiple repl's.
-- Bill Clementson
In article 8757cb490704222232m429a62avf02c9225cb2c68fa@mail.gmail.com, "Bill Clementson" billclem@gmail.com wrote:
Hi Marco,
On 4/20/07, Marco Baringer mb@bese.it wrote:
"Bill Clementson" billclem@gmail.com writes:
Hi Rainer,
On 4/17/07, Rainer Joswig joswig@lisp.de wrote:
I'm a bit used to the behavior of MCL when it comes to Lisp buffers and listeners. Maybe SLIME developers know how to achieve a similar behavior or would like to provide something similar.
MCL allowed multiple Lisp text editor windows and listener windows. If there are multiple listeners one is the front most.
SLIME does allow you to have multiple REPL windows. When you do "M-x slime" multiple times, it will ask you whether you want to create an additional repl.
are you sure? i tried this today and multiple M-x slime will start multiple swank-servers in the lisp but you still only get one repl buffer (this looks a lot like a bug).
Yes, I'm sure. Well, at least I'm sure it does one specific thing (which may not be what you think Rainer wants nor what he actually does want ;-) ). I don't usually use multiple repl's, so I'm not sure I understand the specific use case that Rainer wants to address. As I see it, there may be 3 different types of "new" repl's that one could want to have (which, depending on your specific use case may or may not be what is required):
The basic interaction between an Lisp editor and a Lisp listener is a bit different in MCL. I found it a bit more convenient then what SLIME currently does. In the simple form it is mostly independent from the multiple buffer issue. In my other posting I had explained the MCL interaction a bit more.
#1: You want to "play around" with some ideas but don't want to "muck up" your existing lisp environment and repl. In that case, you probably want to start up a new lisp instance and test things in a completely independent repl. When I do "M-x slime" multiple times (and say "n" to the "Create an additional *inferior-lisp*?" prompt), that is exactly what I get - multiple lisp instances with a separate repl for each one. I can use "C-c C-x c" to switch between them so I can do my "mucking around" in the one repl and do the "real stuff" in the other repl ("C-c C-x c" also controls which repl is "active" when you're in a lisp buffer compiling/evaluating/etc code).
#2: You want to have multiple repl's on the same lisp instance (with each repl sharing the repl history and */**/***/etc values). This is useful if you want to use one repl for a demo but want to be able to enter other commands in another repl to set up or modify an environment for the demo. There are probably other use cases for this; however, this is what I normally use #2 for. Again (as with #1), I can use "C-c C-x c" to switch between the repl's so I have control over which one is "active". Although SLIME does not provide any standard function for automatically creating multiple repl's, it is easy enough to do if you are using a lisp with threads. In your existing SLIME repl, you can just enter "(swank::create-server :port some-port)" and then in emacs do a "M-x slime-connect" and specify the host & port. If you do this a lot, you could automate it with something like the following:
(defun slime-new-repl () "Create additional REPL for the current Lisp connection." (interactive) (if (slime-current-connection) (let ((port (slime-connection-port (slime-connection)))) (slime-eval `(swank::create-server :port ,port)) (slime-connect slime-lisp-host port)) (error "Not connected")))
and just do "M-x slime-new-repl" whenever you wanted a new repl. As you can see from the above function, although you can specify any port, you can also just reuse the existing port for the separate repl, so it's easy enough to do when you're ssh'ing to a remote machine too.
#3: You want to have multiple repl's on the same lisp instance (with each repl having it's own repl history and */**/***/etc values). I thought that it was possible to do this at one time with SLIME; however, I just had a play and I don't think there is any way that you can currently do this in SLIME.
I thought Rainer was after #1 when I initially replied. If he is after #1 or #2, SLIME currently supports these types of multiple repl's. If he was looking for #3, I don't think that is currently supported. Maybe Rainer could indicate what specific use case he is trying to address with multiple repl's.
The basic use case (one Lisp editor buffer and one listener buffer) would be:
Write and execute the code from the editor. The code will be read from the editor using the package of the editor (or *package* if there is none). The execution takes place in the context of the listener. The result is printed in the listener. At the end of the execution the listener prompt is updated (position at the end of the buffer) and the *,**,***,... variables are set/updated.
The streams of the listener will be used. Also the printer settings of the listener will be used for printing the result.
The forms for execution should be entered in a queue and executed one after the other. Pressing C-x C-e (Enter) would execute the first form. If this form is finished, then the second form will be executed. By default a listener has only one execution going on at any one time.
I want C-x C-e to do something different and have it on Enter. ;-) I never use the minibuffer for displaying Lisp results. I'd better leave the minibuffer for command interaction and display of messages.
SLIME (C-x C-e) currently:
SLIME does not print the result of C-x C-e in the Listener. The result is printed in the mini-buffer.
SLIME does not set *,**,*** and related.
SLIME does interfer with its listener prompt in interactions in the listener. If a program prints to the listener or reads from it, the prompt is always moved to the end while doing output.
SLIME (+ OpenMCL) happily executes two forms from the editor via C-x C-e. But it starts the execution of the second form immediately.
-- Bill Clementson
On 4/23/07, Rainer Joswig joswig@lisp.de wrote:
In article 8757cb490704222232m429a62avf02c9225cb2c68fa@mail.gmail.com, "Bill Clementson" billclem@gmail.com wrote:
Hi Marco,
On 4/20/07, Marco Baringer mb@bese.it wrote:
"Bill Clementson" billclem@gmail.com writes:
Hi Rainer,
On 4/17/07, Rainer Joswig joswig@lisp.de wrote:
I'm a bit used to the behavior of MCL when it comes to Lisp buffers and listeners. Maybe SLIME developers know how to achieve a similar behavior or would like to provide something similar.
MCL allowed multiple Lisp text editor windows and listener windows. If there are multiple listeners one is the front most.
SLIME does allow you to have multiple REPL windows. When you do "M-x slime" multiple times, it will ask you whether you want to create an additional repl.
are you sure? i tried this today and multiple M-x slime will start multiple swank-servers in the lisp but you still only get one repl buffer (this looks a lot like a bug).
Yes, I'm sure. Well, at least I'm sure it does one specific thing (which may not be what you think Rainer wants nor what he actually does want ;-) ). I don't usually use multiple repl's, so I'm not sure I understand the specific use case that Rainer wants to address. As I see it, there may be 3 different types of "new" repl's that one could want to have (which, depending on your specific use case may or may not be what is required):
The basic interaction between an Lisp editor and a Lisp listener is a bit different in MCL. I found it a bit more convenient then what SLIME currently does. In the simple form it is mostly independent from the multiple buffer issue. In my other posting I had explained the MCL interaction a bit more.
Yes, but you never really indicated WHY you wanted to use multiple repls. You said that you used them all the time in MCL, but didn't indicate the types of use cases where multiple repls would be of benefit. Of the 3 scenarios I describe below, which one(s) matches your use case for multiple repls?
#1: You want to "play around" with some ideas but don't want to "muck up" your existing lisp environment and repl. In that case, you probably want to start up a new lisp instance and test things in a completely independent repl. When I do "M-x slime" multiple times (and say "n" to the "Create an additional *inferior-lisp*?" prompt), that is exactly what I get - multiple lisp instances with a separate repl for each one. I can use "C-c C-x c" to switch between them so I can do my "mucking around" in the one repl and do the "real stuff" in the other repl ("C-c C-x c" also controls which repl is "active" when you're in a lisp buffer compiling/evaluating/etc code).
#2: You want to have multiple repl's on the same lisp instance (with each repl sharing the repl history and */**/***/etc values). This is useful if you want to use one repl for a demo but want to be able to enter other commands in another repl to set up or modify an environment for the demo. There are probably other use cases for this; however, this is what I normally use #2 for. Again (as with #1), I can use "C-c C-x c" to switch between the repl's so I have control over which one is "active". Although SLIME does not provide any standard function for automatically creating multiple repl's, it is easy enough to do if you are using a lisp with threads. In your existing SLIME repl, you can just enter "(swank::create-server :port some-port)" and then in emacs do a "M-x slime-connect" and specify the host & port. If you do this a lot, you could automate it with something like the following:
(defun slime-new-repl () "Create additional REPL for the current Lisp connection." (interactive) (if (slime-current-connection) (let ((port (slime-connection-port (slime-connection)))) (slime-eval `(swank::create-server :port ,port)) (slime-connect slime-lisp-host port)) (error "Not connected")))
and just do "M-x slime-new-repl" whenever you wanted a new repl. As you can see from the above function, although you can specify any port, you can also just reuse the existing port for the separate repl, so it's easy enough to do when you're ssh'ing to a remote machine too.
#3: You want to have multiple repl's on the same lisp instance (with each repl having it's own repl history and */**/***/etc values). I thought that it was possible to do this at one time with SLIME; however, I just had a play and I don't think there is any way that you can currently do this in SLIME.
I thought Rainer was after #1 when I initially replied. If he is after #1 or #2, SLIME currently supports these types of multiple repl's. If he was looking for #3, I don't think that is currently supported. Maybe Rainer could indicate what specific use case he is trying to address with multiple repl's.
The basic use case (one Lisp editor buffer and one listener buffer) would be:
The following applies for one Lisp editor buffer and one listener, but what is the use case with one Lisp editor buffer and multiple listeners?
Write and execute the code from the editor. The code will be read from the editor using the package of the editor (or *package* if there is none). The execution takes place in the context of the listener. The result is printed in the listener. At the end of the execution the listener prompt is updated (position at the end of the buffer) and the *,**,***,... variables are set/updated.
The streams of the listener will be used. Also the printer settings of the listener will be used for printing the result.
The forms for execution should be entered in a queue and executed one after the other. Pressing C-x C-e (Enter) would execute the first form. If this form is finished, then the second form will be executed. By default a listener has only one execution going on at any one time.
In MCL, what happens if there are multiple forms in the execution queue and one form results in an error? Are the remaining forms still executed?
I want C-x C-e to do something different and have it on Enter. ;-) I never use the minibuffer for displaying Lisp results. I'd better leave the minibuffer for command interaction and display of messages.
SLIME (C-x C-e) currently:
SLIME does not print the result of C-x C-e in the Listener. The result is printed in the mini-buffer.
SLIME does not set *,**,*** and related.
SLIME does interfer with its listener prompt in interactions in the listener. If a program prints to the listener or reads from it, the prompt is always moved to the end while doing output.
SLIME (+ OpenMCL) happily executes two forms from the editor via C-x C-e. But it starts the execution of the second form immediately.
Have you tried out the slime-send-dwim function that I sent you in my previous email yet? It does do everything you describe above with the exception of queueing execution of multiple forms.
-- Bill Clementson
In article 8757cb490704230700l1a58b46em4ba1ade36851c6e1@mail.gmail.com, "Bill Clementson" billclem@gmail.com wrote:
On 4/23/07, Rainer Joswig joswig@lisp.de wrote:
In article 8757cb490704222232m429a62avf02c9225cb2c68fa@mail.gmail.com, "Bill Clementson" billclem@gmail.com wrote:
Hi Marco,
On 4/20/07, Marco Baringer mb@bese.it wrote:
"Bill Clementson" billclem@gmail.com writes:
Hi Rainer,
On 4/17/07, Rainer Joswig joswig@lisp.de wrote:
I'm a bit used to the behavior of MCL when it comes to Lisp buffers and listeners. Maybe SLIME developers know how to achieve a similar behavior or would like to provide something similar.
MCL allowed multiple Lisp text editor windows and listener windows. If there are multiple listeners one is the front most.
SLIME does allow you to have multiple REPL windows. When you do "M-x slime" multiple times, it will ask you whether you want to create an additional repl.
are you sure? i tried this today and multiple M-x slime will start multiple swank-servers in the lisp but you still only get one repl buffer (this looks a lot like a bug).
Yes, I'm sure. Well, at least I'm sure it does one specific thing (which may not be what you think Rainer wants nor what he actually does want ;-) ). I don't usually use multiple repl's, so I'm not sure I understand the specific use case that Rainer wants to address. As I see it, there may be 3 different types of "new" repl's that one could want to have (which, depending on your specific use case may or may not be what is required):
The basic interaction between an Lisp editor and a Lisp listener is a bit different in MCL. I found it a bit more convenient then what SLIME currently does. In the simple form it is mostly independent from the multiple buffer issue. In my other posting I had explained the MCL interaction a bit more.
Yes, but you never really indicated WHY you wanted to use multiple repls. You said that you used them all the time in MCL, but didn't indicate the types of use cases where multiple repls would be of benefit. Of the 3 scenarios I describe below, which one(s) matches your use case for multiple repls?
The multiple REPLs are usually connected to one Lisp. The REPLs: * could be in different packages, could have different I/O settings, ... * could execute different long-running tasks (like rendering a bunch of HTML to a file from some data) * one REPL could be for debugging, the other for a long running execution or to create output. * sometimes you create a version of REPL which does run another embedded language (Scheme, ....) from the same Lisp.
#1: You want to "play around" with some ideas but don't want to "muck up" your existing lisp environment and repl. In that case, you probably want to start up a new lisp instance and test things in a completely independent repl. When I do "M-x slime" multiple times (and say "n" to the "Create an additional *inferior-lisp*?" prompt), that is exactly what I get - multiple lisp instances with a separate repl for each one. I can use "C-c C-x c" to switch between them so I can do my "mucking around" in the one repl and do the "real stuff" in the other repl ("C-c C-x c" also controls which repl is "active" when you're in a lisp buffer compiling/evaluating/etc code).
#2: You want to have multiple repl's on the same lisp instance (with each repl sharing the repl history and */**/***/etc values). This is useful if you want to use one repl for a demo but want to be able to enter other commands in another repl to set up or modify an environment for the demo. There are probably other use cases for this; however, this is what I normally use #2 for. Again (as with #1), I can use "C-c C-x c" to switch between the repl's so I have control over which one is "active". Although SLIME does not provide any standard function for automatically creating multiple repl's, it is easy enough to do if you are using a lisp with threads. In your existing SLIME repl, you can just enter "(swank::create-server :port some-port)" and then in emacs do a "M-x slime-connect" and specify the host & port. If you do this a lot, you could automate it with something like the following:
(defun slime-new-repl () "Create additional REPL for the current Lisp connection." (interactive) (if (slime-current-connection) (let ((port (slime-connection-port (slime-connection)))) (slime-eval `(swank::create-server :port ,port)) (slime-connect slime-lisp-host port)) (error "Not connected")))
and just do "M-x slime-new-repl" whenever you wanted a new repl. As you can see from the above function, although you can specify any port, you can also just reuse the existing port for the separate repl, so it's easy enough to do when you're ssh'ing to a remote machine too.
#3: You want to have multiple repl's on the same lisp instance (with each repl having it's own repl history and */**/***/etc values). I thought that it was possible to do this at one time with SLIME; however, I just had a play and I don't think there is any way that you can currently do this in SLIME.
I thought Rainer was after #1 when I initially replied. If he is after #1 or #2, SLIME currently supports these types of multiple repl's. If he was looking for #3, I don't think that is currently supported. Maybe Rainer could indicate what specific use case he is trying to address with multiple repl's.
The basic use case (one Lisp editor buffer and one listener buffer) would be:
The following applies for one Lisp editor buffer and one listener, but what is the use case with one Lisp editor buffer and multiple listeners?
That's not used that much. Mostly it is many Editor buffers and one or two listeners.
I use one Editor and two listeners sometimes. All the forms I define, the data and the test forms are in the editor buffer. One listener is for debugging (using break loops) and execution of code. The other one is for testing out forms and redefining forms. Both get their input from the one editor buffer.
Write and execute the code from the editor. The code will be read from the editor using the package of the editor (or *package* if there is none). The execution takes place in the context of the listener. The result is printed in the listener. At the end of the execution the listener prompt is updated (position at the end of the buffer) and the *,**,***,... variables are set/updated.
The streams of the listener will be used. Also the printer settings of the listener will be used for printing the result.
The forms for execution should be entered in a queue and executed one after the other. Pressing C-x C-e (Enter) would execute the first form. If this form is finished, then the second form will be executed. By default a listener has only one execution going on at any one time.
In MCL, what happens if there are multiple forms in the execution queue and one form results in an error? Are the remaining forms still executed?
Unless there is some other error handling going on, you get a break loop in the listener. After successful continuing from the error and successful execution of the first form the next form gets taken from the queue and executed.
I want C-x C-e to do something different and have it on Enter. ;-) I never use the minibuffer for displaying Lisp results. I'd better leave the minibuffer for command interaction and display of messages.
SLIME (C-x C-e) currently:
SLIME does not print the result of C-x C-e in the Listener. The result is printed in the mini-buffer.
SLIME does not set *,**,*** and related.
SLIME does interfer with its listener prompt in interactions in the listener. If a program prints to the listener or reads from it, the prompt is always moved to the end while doing output.
SLIME (+ OpenMCL) happily executes two forms from the editor via C-x C-e. But it starts the execution of the second form immediately.
Have you tried out the slime-send-dwim function that I sent you in my previous email yet? It does do everything you describe above with the exception of queueing execution of multiple forms.
Yes, I have tried it. Thanks!
A few glitches:
* If I send a defun, after executing it, the cursor is not moved to the new prompt at the end of the listener buffer. * if the cursor is on the end of a line behind a form and there is a form on the next line, the next form will be taken. * after execution the cursor in the listener is not moved to the prompt. * it does not take into account that the Lisp editor buffer package could be different from the Listener.
As I have mentioned earlier, I think the interaction between an Editor and a Listener is one issue. The other one is this interaction in the presence of multiple Lisp editor buffers or listeners. I understand that a full MCL-like interaction might not be possible or even not desirable in Emacs, but I think the basic Editor/Listener user experience of Slime could benefit from some other ideas.
Regards,
Rainer Joswig
-- Bill Clementson
On 4/23/07, Rainer Joswig joswig@lisp.de wrote:
In article 8757cb490704230700l1a58b46em4ba1ade36851c6e1@mail.gmail.com, "Bill Clementson" billclem@gmail.com wrote:
On 4/23/07, Rainer Joswig joswig@lisp.de wrote:
In article 8757cb490704222232m429a62avf02c9225cb2c68fa@mail.gmail.com, "Bill Clementson" billclem@gmail.com wrote:
Hi Marco,
On 4/20/07, Marco Baringer mb@bese.it wrote:
"Bill Clementson" billclem@gmail.com writes:
Hi Rainer,
On 4/17/07, Rainer Joswig joswig@lisp.de wrote: > I'm a bit used to the behavior of MCL when it comes > to Lisp buffers and listeners. Maybe SLIME developers > know how to achieve a similar behavior or would like > to provide something similar. > > MCL allowed multiple Lisp text editor windows and listener windows. > If there are multiple listeners one is the front most.
SLIME does allow you to have multiple REPL windows. When you do "M-x slime" multiple times, it will ask you whether you want to create an additional repl.
are you sure? i tried this today and multiple M-x slime will start multiple swank-servers in the lisp but you still only get one repl buffer (this looks a lot like a bug).
Yes, I'm sure. Well, at least I'm sure it does one specific thing (which may not be what you think Rainer wants nor what he actually does want ;-) ). I don't usually use multiple repl's, so I'm not sure I understand the specific use case that Rainer wants to address. As I see it, there may be 3 different types of "new" repl's that one could want to have (which, depending on your specific use case may or may not be what is required):
The basic interaction between an Lisp editor and a Lisp listener is a bit different in MCL. I found it a bit more convenient then what SLIME currently does. In the simple form it is mostly independent from the multiple buffer issue. In my other posting I had explained the MCL interaction a bit more.
Yes, but you never really indicated WHY you wanted to use multiple repls. You said that you used them all the time in MCL, but didn't indicate the types of use cases where multiple repls would be of benefit. Of the 3 scenarios I describe below, which one(s) matches your use case for multiple repls?
The multiple REPLs are usually connected to one Lisp. The REPLs:
- could be in different packages, could have different I/O settings, ...
- could execute different long-running tasks (like rendering a bunch of HTML to a file from some data)
- one REPL could be for debugging, the other for a long running execution or to create output.
- sometimes you create a version of REPL which does run another embedded language (Scheme, ....) from the same Lisp.
#1: You want to "play around" with some ideas but don't want to "muck up" your existing lisp environment and repl. In that case, you probably want to start up a new lisp instance and test things in a completely independent repl. When I do "M-x slime" multiple times (and say "n" to the "Create an additional *inferior-lisp*?" prompt), that is exactly what I get - multiple lisp instances with a separate repl for each one. I can use "C-c C-x c" to switch between them so I can do my "mucking around" in the one repl and do the "real stuff" in the other repl ("C-c C-x c" also controls which repl is "active" when you're in a lisp buffer compiling/evaluating/etc code).
#2: You want to have multiple repl's on the same lisp instance (with each repl sharing the repl history and */**/***/etc values). This is useful if you want to use one repl for a demo but want to be able to enter other commands in another repl to set up or modify an environment for the demo. There are probably other use cases for this; however, this is what I normally use #2 for. Again (as with #1), I can use "C-c C-x c" to switch between the repl's so I have control over which one is "active". Although SLIME does not provide any standard function for automatically creating multiple repl's, it is easy enough to do if you are using a lisp with threads. In your existing SLIME repl, you can just enter "(swank::create-server :port some-port)" and then in emacs do a "M-x slime-connect" and specify the host & port. If you do this a lot, you could automate it with something like the following:
(defun slime-new-repl () "Create additional REPL for the current Lisp connection." (interactive) (if (slime-current-connection) (let ((port (slime-connection-port (slime-connection)))) (slime-eval `(swank::create-server :port ,port)) (slime-connect slime-lisp-host port)) (error "Not connected")))
and just do "M-x slime-new-repl" whenever you wanted a new repl. As you can see from the above function, although you can specify any port, you can also just reuse the existing port for the separate repl, so it's easy enough to do when you're ssh'ing to a remote machine too.
#3: You want to have multiple repl's on the same lisp instance (with each repl having it's own repl history and */**/***/etc values). I thought that it was possible to do this at one time with SLIME; however, I just had a play and I don't think there is any way that you can currently do this in SLIME.
I thought Rainer was after #1 when I initially replied. If he is after #1 or #2, SLIME currently supports these types of multiple repl's. If he was looking for #3, I don't think that is currently supported. Maybe Rainer could indicate what specific use case he is trying to address with multiple repl's.
The basic use case (one Lisp editor buffer and one listener buffer) would be:
The following applies for one Lisp editor buffer and one listener, but what is the use case with one Lisp editor buffer and multiple listeners?
That's not used that much. Mostly it is many Editor buffers and one or two listeners.
I use one Editor and two listeners sometimes. All the forms I define, the data and the test forms are in the editor buffer. One listener is for debugging (using break loops) and execution of code. The other one is for testing out forms and redefining forms. Both get their input from the one editor buffer.
Write and execute the code from the editor. The code will be read from the editor using the package of the editor (or *package* if there is none). The execution takes place in the context of the listener. The result is printed in the listener. At the end of the execution the listener prompt is updated (position at the end of the buffer) and the *,**,***,... variables are set/updated.
The streams of the listener will be used. Also the printer settings of the listener will be used for printing the result.
The forms for execution should be entered in a queue and executed one after the other. Pressing C-x C-e (Enter) would execute the first form. If this form is finished, then the second form will be executed. By default a listener has only one execution going on at any one time.
In MCL, what happens if there are multiple forms in the execution queue and one form results in an error? Are the remaining forms still executed?
Unless there is some other error handling going on, you get a break loop in the listener. After successful continuing from the error and successful execution of the first form the next form gets taken from the queue and executed.
I want C-x C-e to do something different and have it on Enter. ;-) I never use the minibuffer for displaying Lisp results. I'd better leave the minibuffer for command interaction and display of messages.
SLIME (C-x C-e) currently:
SLIME does not print the result of C-x C-e in the Listener. The result is printed in the mini-buffer.
SLIME does not set *,**,*** and related.
SLIME does interfer with its listener prompt in interactions in the listener. If a program prints to the listener or reads from it, the prompt is always moved to the end while doing output.
SLIME (+ OpenMCL) happily executes two forms from the editor via C-x C-e. But it starts the execution of the second form immediately.
Have you tried out the slime-send-dwim function that I sent you in my previous email yet? It does do everything you describe above with the exception of queueing execution of multiple forms.
Yes, I have tried it. Thanks!
A few glitches:
One man's "glitch" is another man's "feature" ;-)
As I mentioned, this is code that I use for doing presentations and all of the things that you are seeing are intentional. I sent you the code so that you could try it and see whether it provided the type of interaction with the repl that you were after (with the idea that you might need to modify it to provide the specific behaviour you're after).
- If I send a defun, after executing it, the cursor is not moved to the new prompt at the end of the listener buffer.
When a defun is executed (e.g. - with C-u F9), the entire defun is copied to the repl and executed and the "active" buffer is the editor buffer (this is because I use this code for presentations and I want to just cursor down to the next form and execute it).
When a defun is copied to the repl (e.g. - with F9 only), the repl buffer is the "active" buffer (this is because I will usually be talking about the form before I press enter to execute it).
- if the cursor is on the end of a line behind a form and there is a form on the next line, the next form will be taken.
As I mentioned, this is code that I use for doing presentations and I want it to send a form to the listener sometimes when the point is at the beginning of the form, sometimes when it is at the end of the form and sometimes when it is in the form. Since the point may be both after an end paren and before an open paren at the same time, certain evaluation rules apply and this is why the second form is being evaluated in the example you gave. If you always only want the preceeding form to be evaluated, you could place the cursor ON the end paren (or begin paren) of the form you want executed. Or, you could modify the code to suit your specific form-selection rules.
- after execution the cursor in the listener is not moved to the prompt.
It depends on whether you want to have the form just copied to the repl or copied and executed as to whether the repl becomes the "active" buffer or not. If the form is just copied (e.g. - with F9), then the repl buffer becomes the "active" buffer and the cursor is positioned at the end of the form. Normally, the user then either edits the form in the repl or just presses enter. If the form is copied & executed (e.g. - with C-u F9), then the editor buffer remains the "active" buffer and the cursor is not moved.
- it does not take into account that the Lisp editor buffer package could be different from the Listener.
That is true. If I want to sync the Lisp editor buffer package with the Listener, I would normally do "C-c ~" (slime-sync-package-and-default-directory).
As I have mentioned earlier, I think the interaction between an Editor and a Listener is one issue. The other one is this interaction in the presence of multiple Lisp editor buffers or listeners. I understand that a full MCL-like interaction might not be possible or even not desirable in Emacs, but I think the basic Editor/Listener user experience of Slime could benefit from some other ideas.
Yes, I probably misunderstood what you were saying in your original email. I thought you were looking for a solution to a specific problem and therefore tried to provide something that might help. However, I now realize that you were commenting on a different model of repl interaction and suggesting that something like this might be a more appropriate (or, perhaps, alternative) means of interaction in SLIME.
Cheers, Bill
* Rainer Joswig joswig-F04898.17115523042007@news.gmane.org : | * If I send a defun, after executing it, the cursor is not moved to | the new prompt at the end of the listener buffer. | * if the cursor is on the end of a line behind a form and there is a | form on the next line, the next form will be taken. | * after execution the cursor in the listener is not moved to the | prompt. | * it does not take into account that the Lisp editor buffer package | could be different from the Listener.
IIRC it used to be possible to easily evaluate the current sexp in a lisp buffer, in the "current" SLIME REPL, using the correct package and read-table package of the current lisp buffer, while including both the evaluated form and output in the SLIME REPL buffer: Sketch:
(let ((form (slime-defun-at-point)) (buffer-name (buffer-name (current-buffer))) (package-name (slime-find-buffer-package))) (with-current-buffer (slime-output-buffer) (slime-with-output-end-mark (unless (bolp) (insert "\n")) (insert ";;;; Evaluating form from buffer " buffer-name " in package " package-name ".\n" form "\n;;;; Results: \n") (slime-repl-eval-string form) (insert ";;;; Done.\n"))))
However, at present this will not work. I think because of swank protocol changes involving :repl-result, which I believe were introduced to support presentations. At present it is not clear (to me) what the protocol is for moving the point and inserting the prompt in the SLIME REPL.
There is also, I believe, at present, a bug in that protocol: Any input entered (at the keyboard by the user) in the SLIME REPL buffer when slime is evaluating a form, is wiped out when slime finishes evaluating the form and prinpts the prompt. This can be irritating at times.
Resolving these issues would be the first step towards interacting with multiple SLIME REPLs.
Regarding queueing forms, I wanted to note that with a non SPAWN communication style, at present, remote evaluations do get queued per connection. For example, in CMUCL started inside a terminal, Sketch:
* (mp:make-process (lambda () (swank:setup-server 4005 ...) :name "Swank4005)) * (mp:make-process (lambda () (swank:setup-server 4006 ...) :name "Swank4006))
and then using `slime-connect' to open two connections lets me queue forms for evaluation on each individual connection.
This is far from robust, but could be made so. Note, at present support for this is not inside slime (via communication style), but on top of it, and slime would need rework to support it directly. -- Madhu
Madhu enometh@meer.net writes:
There is also, I believe, at present, a bug in that protocol: Any input entered (at the keyboard by the user) in the SLIME REPL buffer when slime is evaluating a form, is wiped out when slime finishes evaluating the form and prinpts the prompt. This can be irritating at times.
Hm, if I do type (sleep 20) RET 'KABOOM RET on the REPL, the symbol will be evaluated right after SLEEP returned. Are you talking about something else?
-T.
* "Tobias C. Rittweiler" 87y7kf89c4.fsf@freebits.de : |> There is also, I believe, at present, a bug in that protocol: Any |> input entered (at the keyboard by the user) in the SLIME REPL buffer |> when slime is evaluating a form, is wiped out when slime finishes |> evaluating the form and prinpts the prompt. This can be irritating at |> times. | | Hm, if I do type (sleep 20) RET 'KABOOM RET on the REPL, the symbol will | be evaluated right after SLEEP returned. Are you talking about something | else?
Try (sleep 20) <RET> 'KABOOM but don't try <RET> again
When the form finishes execution, your input, `KABOOM', is erased. KABOOM could be some Lisp expression of course that you are in the middle of typing.
-- Madhu
I verified this for both values of SWANK:*USE-DEDICATED-OUTPUT-STREAM*.
Compare this with what happens in comint modes
Madhu enometh@meer.net wrote on 2007-04-24:
There is also, I believe, at present, a bug in that protocol: Any input entered (at the keyboard by the user) in the SLIME REPL buffer when slime is evaluating a form, is wiped out when slime finishes evaluating the form and prinpts the prompt. This can be irritating at times.
I have fixed this in CVS.
On 23-Apr-07, at 4:17 AM, Rainer Joswig wrote:
The basic use case (one Lisp editor buffer and one listener buffer) would be:
[behaviour description snipped]
As a regular slime user, I can say that I would appreciate this kind of behaviour.
"Bill Clementson" billclem@gmail.com writes:
[...] As I see it, there may be 3 different types of "new" repl's that one could want to have [...]:
#1: You want to "play around" with some ideas but don't want to "muck up" your existing lisp environment and repl. In that case, you probably want to start up a new lisp instance and test things in a completely independent repl. When I do "M-x slime" multiple times (and say "n" to the "Create an additional *inferior-lisp*?" prompt), that is exactly what I get - multiple lisp instances with a separate repl for each one.
I think you meant pressing `y' rather than `n' on the "Create an additional *inferior-lisp*?" prompt, as `n' is more or less (maybe even exactly) tantamount to ,restart-inferior-lisp on the REPL.
#2: You want to have multiple repl's on the same lisp instance (with each repl sharing the repl history and */**/***/etc values). [...]
(defun slime-new-repl () "Create additional REPL for the current Lisp connection." (interactive) (if (slime-current-connection) (let ((port (slime-connection-port (slime-connection)))) (slime-eval `(swank::create-server :port ,port)) (slime-connect slime-lisp-host port)) (error "Not connected")))
and just do "M-x slime-new-repl" whenever you wanted a new repl. [...]
#3: You want to have multiple repl's on the same lisp instance (with each repl having it's own repl history and */**/***/etc values). I thought that it was possible to do this at one time with SLIME; however, I just had a play and I don't think there is any way that you can currently do this in SLIME.
It may be possible to do it similiarly to your above function, but making CL:*, CL:**, CL:*** &c thread-local.
-T.
On 4/26/07, Tobias C. Rittweiler tcr@freebits.de wrote:
"Bill Clementson" billclem@gmail.com writes:
[...] As I see it, there may be 3 different types of "new" repl's that one could want to have [...]:
#1: You want to "play around" with some ideas but don't want to "muck up" your existing lisp environment and repl. In that case, you probably want to start up a new lisp instance and test things in a completely independent repl. When I do "M-x slime" multiple times (and say "n" to the "Create an additional *inferior-lisp*?" prompt), that is exactly what I get - multiple lisp instances with a separate repl for each one.
I think you meant pressing `y' rather than `n' on the "Create an additional *inferior-lisp*?" prompt, as `n' is more or less (maybe even exactly) tantamount to ,restart-inferior-lisp on the REPL.
Yes, you're right - I meant "y".
#2: You want to have multiple repl's on the same lisp instance (with each repl sharing the repl history and */**/***/etc values). [...]
(defun slime-new-repl () "Create additional REPL for the current Lisp connection." (interactive) (if (slime-current-connection) (let ((port (slime-connection-port (slime-connection)))) (slime-eval `(swank::create-server :port ,port)) (slime-connect slime-lisp-host port)) (error "Not connected")))
and just do "M-x slime-new-repl" whenever you wanted a new repl. [...]
#3: You want to have multiple repl's on the same lisp instance (with each repl having it's own repl history and */**/***/etc values). I thought that it was possible to do this at one time with SLIME; however, I just had a play and I don't think there is any way that you can currently do this in SLIME.
It may be possible to do it similiarly to your above function, but making CL:*, CL:**, CL:*** &c thread-local.
I think there's probably more work involved in making the repls completely independent, but that would be a start.
- Bill
Rainer Joswig joswig@lisp.de writes:
I'm a bit used to the behavior of MCL when it comes to Lisp buffers and listeners. Maybe SLIME developers know how to achieve a similar behavior or would like to provide something similar.
Hi Rainer,
I think what you want is better support for using a Lisp buffer as scratch buffer (as it's commonly called on modern Emacsen); Someone (Brian Downing?) had some ideas on how to improve support for this kind of development, IIRC.
What I'd really like is something that can fetch an s-exp and all its relevant lexical context (LET, FLET/LABELS, MACROLET, SYMBOL-MACROLET bindings) and copy it over to the REPL (without executing it.) :)
(Cutting down a sexp to the relevant parts isn't that bad with paredit.el, though. Btw., Rainer, you do know about paredit.el, don't you? :))
-T.
-
Bill Clementson -
Gary King -
Geoff Wozniak -
Madhu -
Marco Baringer -
Matthias Koeppe -
Nikodemus Siivola -
Rainer Joswig -
Tobias C. Rittweiler