It would be better for the remaining connection to become default when I quit the default one.
On Wed, Sep 10, 2008 at 7:17 PM, Stas Boukarev stassats@gmail.com wrote:
It would be better for the remaining connection to become default when I quit the default one.
I don't know what is better: use the previous connection or use the connection if it is the only remained. The attached patch is doing the former.
* Stas Boukarev [2008-09-16 01:35+0200] writes:
I don't know what is better: use the previous connection or use the connection if it is the only remained. The attached patch is doing the former.
I added a customizable variable, slime-auto-select-connection. The default is to ask if the connection should be switched. If you set the variable to 'always the first connection will be used.
Helmut.
Helmut Eller wrote:
- Stas Boukarev [2008-09-16 01:35+0200] writes:
I don't know what is better: use the previous connection or use the connection if it is the only remained. The attached patch is doing the former.
I added a customizable variable, slime-auto-select-connection. The default is to ask if the connection should be switched. If you set the variable to 'always the first connection will be used.
I have this in my .emacs file. By pressing F12, I make the default-connection a buffer-local variable. As I usualy have several differen lisps running at the same time, with different lisp code.
(defun slime-toggle-connection () "Change current slime connection, and make it buffer local" (interactive) (setf slime-net-processes (rotate-list slime-net-processes)) (let ((p (car slime-net-processes))) (make-local-variable 'slime-default-connection) (slime-select-connection p) (message "Lisp: %s, buffer: %s" (process-contact p) (slime-connection-name p))))
(define-key slime-mode-map [f12] 'slime-toggle-connection) (define-key slime-mode-map [f11] 'slime-goto-current-connection)
* Knut Olav Bøhmer [2008-09-22 11:25+0200] writes:
I have this in my .emacs file. By pressing F12, I make the default-connection a buffer-local variable. As I usualy have several differen lisps running at the same time, with different lisp code.
I've added this to SLIME, with the name slime-cycle-connections. No key-binding, though.
Helmut.
Helmut Eller heller@common-lisp.net writes:
I've added this to SLIME, with the name slime-cycle-connections. No key-binding, though.
What is the reason that this function tries to make the new connection buffer-local?
I just committed not to do that when we're inside a REPL buffer; but it doesn't make much sense for .lisp buffers either, or SLDB buffers, or the inspector, or..
-T.
Tobias C. Rittweiler wrote:
Helmut Eller heller@common-lisp.net writes:
I've added this to SLIME, with the name slime-cycle-connections. No key-binding, though.
What is the reason that this function tries to make the new connection buffer-local?
That is not what this function are doing. it is not to make a new connection buffer-local. You make the current-connection variable, buffer-local. That could be an old, still running, lisp connection, and an old lisp-buffer. If you have multiple lisp images running, with different source for the different images. Then having to switch current-connection when jumping between buffers, saves a lot of frustration.
Example: I have one lisp running the web-server, using a different lisp with business logic. Then if I change something in the interface between the two lisps, I would change something the business-logic-image (C-x C-c in the source-file for the business-logic-image). Then I would have to change something in the web-server-image. This is where I save time, as I have already set current-connection buffer-local to the web-server-image. So I just press C-x C-c in the source-file for the web-server-image. Then maybe I want to improve it, so I jump back and fourth several times.
I just committed not to do that when we're inside a REPL buffer; but it doesn't make much sense for .lisp buffers either, or SLDB buffers, or the inspector, or..
Right, it does not make sense for REPL, SLDB or inspector. But as you can see from the example above: It makes a lot of sense for .lisp files, and I use it every day.
Knut Olav Bøhmer knut-olav.bohmer@telenor.com writes:
I just committed not to do that when we're inside a REPL buffer; but it doesn't make much sense for .lisp buffers either, or SLDB buffers, or the inspector, or..
Right, it does not make sense for REPL, SLDB or inspector. But as you can see from the example above: It makes a lot of sense for .lisp files, and I use it every day.
I didn't understand your example. Perhaps you're looking for an extra command to make the current connection buffer-local in a buffer.
Slime-cycle-connections making the new connection buffer-local means for example that making another connection the default connection via slime-list-connections will lead to surprises.
Additionally, buffer-local connections can become stale, rendering the .lisp buffer useless.
-T.
Tobias C. Rittweiler wrote:
Knut Olav Bøhmer knut-olav.bohmer@telenor.com writes:
I just committed not to do that when we're inside a REPL buffer; but it doesn't make much sense for .lisp buffers either, or SLDB buffers, or the inspector, or..
Right, it does not make sense for REPL, SLDB or inspector. But as you can see from the example above: It makes a lot of sense for .lisp files, and I use it every day.
I didn't understand your example. Perhaps you're looking for an extra command to make the current connection buffer-local in a buffer.
Ok, say stop where you fall off. --- Example --- I have two different lisp images running in one emacs. One business-logic-image, and one web-server-image There is one source file for image the business-logic-image (lets call it the business-logic-file), and a different file for the web-server-image (lets call it the web-server-file) When I press C-x C-e in the business-logic-file, I want the lisp-form to be evaluated in the business-logic-file When I press C-x C-e in the web-server-file, I want the lisp-form to be evaluated in the web-server-file Then if I shall do a change in my system that requires changes in both web-server and business-logic, then I have to change default connection, at least once. If the development-cycle requires several iterations. Either because I want to improve the code, add features, or debug. I would have to change default connection back and fourth several times. Then it would be better to have the connection buffer-local, so I would not have to change it in every development cycle. ------
And I don't want to make the current default-connection buffer-local. In my experience, this would require many more steps of interacting with Emacs to get the desired result. (step 1: selcect a different default-connection. Step 2: make it buffer-local. Step 3: go to a different-buffer, that does not have a buffer-local default-connection. Step 4: select the original default-connection, to restore desired behaviour. So that we don't forget this later. Step 5: jump back to the special customized buffer, to complete your work)
I want a different connection from the current default-connection to be the buffer-local default-connection. The reason that I don't what the current default-connection to be buffer-local, should be obvious. If I wanted to use the default-connection, then I would not have to make it buffer-local.
Slime-cycle-connections making the new connection buffer-local means for example that making another connection the default connection via slime-list-connections will lead to surprises.
There will be no surprises. You will anyway need to keep track of your connection. You can do that by looking at the connection-name in the mode-line. You will also have to have to know what kind of source-code you are evaluating, then you would know which lisp-image it should be evaluated in.
Additionally, buffer-local connections can become stale, rendering the .lisp buffer useless.
If the buffer-local connection become sale, you will avoid running lisp-commands in another random default connection. You would then have to restart your lisp-image, or connect again. Then select the connection as buffer-local for that buffer. Anyway this is not an hindrance, to implement this functionality. It's merely an interesting beginners hacking assignment, to pop up buffer with the connection-list if the connection is broken.
Knut Olav Bøhmer knut-olav.bohmer@telenor.com writes:
Tobias C. Rittweiler wrote:
Slime-cycle-connections making the new connection buffer-localmeans for example that making another connection the default connection via slime-list-connections will lead to surprises.
There will be no surprises. You will anyway need to keep track of your connection. You can do that by looking at the connection-name in the mode-line.
It will lead to surprises, as the connection to become the new default won't become the connection of .lisp buffers you used `slime-cycle-connection' in.
Additionally, buffer-local connections can become stale, renderingthe .lisp buffer useless.
If the buffer-local connection become sale, you will avoid running lisp-commands in another random default connection.
It became only stale because it was unnecessarily made buffer-local by `slime-cycle-connection'.
I'll remove the line in question. It seems to be highly specific to your personal use case; you can easily write something for your own personal use on top of a `slime-cycle-connection' that doesn't make the new connection buffer-local automatically.
-T.
I think you are misunderstanding the purpose of the feature. It seems to me very valuable when one works with more then one lisp, i.e. connection at a time.
Being able to do C-c C-c in a buffer without worrying which lisp it's going to go to is a good thing.
Roman
On Sep 26, 2008, at 2:13 PM, Tobias C. Rittweiler wrote:
Knut Olav Bøhmer knut-olav.bohmer@telenor.com writes:
Tobias C. Rittweiler wrote:
Slime-cycle-connections making the new connection buffer-local means for example that making another connection the default connection via slime-list-connections will lead to surprises.
There will be no surprises. You will anyway need to keep track of your connection. You can do that by looking at the connection-name in the mode-line.
It will lead to surprises, as the connection to become the new default won't become the connection of .lisp buffers you used `slime-cycle-connection' in.
Additionally, buffer-local connections can become stale, rendering the .lisp buffer useless.
If the buffer-local connection become sale, you will avoid running lisp-commands in another random default connection.
It became only stale because it was unnecessarily made buffer-local by `slime-cycle-connection'.
I'll remove the line in question. It seems to be highly specific to your personal use case; you can easily write something for your own personal use on top of a `slime-cycle-connection' that doesn't make the new connection buffer-local automatically.
-T.
slime-devel site list slime-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/slime-devel
Roman Budzianowski roman.j@budzianowski.net writes:
I think you are misunderstanding the purpose of the feature. It seems to me very valuable when one works with more then one lisp, i.e. connection at a time.
Being able to do C-c C-c in a buffer without worrying which lisp it's going to go to is a good thing.
That's why I proposed to add another command to make a connection buffer-local. But it's not something that follows from a command called `slime-cycle-connection'.
-T.
* Tobias C. Rittweiler [2008-09-26 23:52+0200] writes:
Being able to do C-c C-c in a buffer without worrying which lisp it's going to go to is a good thing.
That's why I proposed to add another command to make a connection buffer-local.
And what would that other command do? Select a connection, other than the current connection, and make it buffer local?
But it's not something that follows from a command called `slime-cycle-connection'.
slime-cycle-connections does what it is supposed to do, ie. it does what the docstring says.
What are you complaining about?
A) the name "slime-cycle-connections" B) that slime-cycle-connections changes slime-default-connection C) that slime-cycle-connections changes slime-buffer-connection D) something else
If you can't stand the name, then change the name.
B) is debatable, but might be convenient.
C) is the main purpose of the command. If you delete that part you can just as well remove the entire command.
Helmut.
Helmut Eller heller@common-lisp.net writes:
- Tobias C. Rittweiler [2008-09-26 23:52+0200] writes:
Being able to do C-c C-c in a buffer without worrying which lisp it's going to go to is a good thing.
That's why I proposed to add another command to make a connection buffer-local.
And what would that other command do? Select a connection, other than the current connection, and make it buffer local?
Prompt the user for a connection (with completion) to be made buffer-local; the next connection could be the prompt's default.
But it's not something that follows from a command called `slime-cycle-connection'.
slime-cycle-connections does what it is supposed to do, ie. it does what the docstring says.
What are you complaining about?
A) the name "slime-cycle-connections" B) that slime-cycle-connections changes slime-default-connection C) that slime-cycle-connections changes slime-buffer-connection D) something else
If you can't stand the name, then change the name.
B) is debatable, but might be convenient.
C) is the main purpose of the command. If you delete that part you can just as well remove the entire command.
It's C).
I read "slime-cycle-connections" as "slime-cycle-default-connection". I'd use it when I've got a .lisp buffer open and want to test some things in it in different implementations.
-T.
* Tobias C. Rittweiler [2008-09-27 18:47+0200] writes:
And what would that other command do? Select a connection, other than the current connection, and make it buffer local?
Prompt the user for a connection (with completion) to be made buffer-local; the next connection could be the prompt's default.
Cycling through a list may well be faster than completion, especially if the list is short.
But it's not something that follows from a command called `slime-cycle-connection'.
slime-cycle-connections does what it is supposed to do, ie. it does what the docstring says.
What are you complaining about?
A) the name "slime-cycle-connections" B) that slime-cycle-connections changes slime-default-connection C) that slime-cycle-connections changes slime-buffer-connection D) something else
If you can't stand the name, then change the name.
B) is debatable, but might be convenient.
C) is the main purpose of the command. If you delete that part you can just as well remove the entire command.
It's C).
I read "slime-cycle-connections" as "slime-cycle-default-connection".
That's not the intention of the command. The part about making the connection specific to the buffer is essential. I think that renaming slime-cycle-connections to something like slime-cycle-buffer-connection would solve the issue.
I'd use it when I've got a .lisp buffer open and want to test some things in it in different implementations.
For this purpose you could also use slime-cycle-connections as it is now.
Helmut.
Helmut Eller heller@common-lisp.net writes:
- Tobias C. Rittweiler [2008-09-27 18:47+0200] writes:
I'd use it when I've got a .lisp buffer open and want to test some things in it in different implementations.
For this purpose you could also use slime-cycle-connections as it is now.
Unfortunately not. In my setup I have a few .lisp buffers open, and if I use `slime-cycle-connections' in buffer A, then a bit later in buffer B, the connection of buffer A ist untouched.
I'll do the following changes if you agree to them:
a) Introduce `slime-set-buffer-local-connection' that does the prompting I mentioned in my previous mail.
b) Introduce `slime-cycle-default-connection' that changes the default connection only.
c) Rename `slime-cycle-connections' to `slime-cycle-buffer-connection' and implement it on top of the above to functions.
All three functions seem to be useful.
-T.
Tobias C. Rittweiler wrote:
[snipped...]
Unfortunately not. In my setup I have a few .lisp buffers open, and if I use `slime-cycle-connections' in buffer A, then a bit later in buffer B, the connection of buffer A ist untouched.
I'll do the following changes if you agree to them:
a) Introduce `slime-set-buffer-local-connection' that does the prompting I mentioned in my previous mail.
b) Introduce `slime-cycle-default-connection' that changes the default connection only.
c) Rename `slime-cycle-connections' to `slime-cycle-buffer-connection' and implement it on top of the above to functions.
All three functions seem to be useful.
Perfect! Thanks
* Tobias C. Rittweiler [2008-09-28 12:18+0200] writes:
[...]
I'll do the following changes if you agree to them:
I agree.
a) Introduce `slime-set-buffer-local-connection' that does the prompting I mentioned in my previous mail.
b) Introduce `slime-cycle-default-connection' that changes the default connection only.
c) Rename `slime-cycle-connections' to `slime-cycle-buffer-connection' and implement it on top of the above to functions.
All three functions seem to be useful.
Three commands for almost the same functionality is a bit bloated. Let's hope that those only need a page of code.
Helmut.
* "Tobias C. Rittweiler" 87iqsh5yer.fsf@freebits.de : Wrote on Sat, 27 Sep 2008 18:47:08 +0200: | | I read "slime-cycle-connections" as | "slime-cycle-default-connection". I'd use it when I've got a .lisp | buffer open and want to test some things in it in different | implementations.
I often wish to send forms for evaluation to different slime connections when looking at a file, by switching default connections. There is no command in slime for cycling the default connection. Looking at the name I'd expect slime-cycle-connection to switch the global default connection.
So I'm agreeing with tcr that a different command could be provided for making the connection buffer local. [then, at least I can reopen the file if I want to use the default global connection for that file.]
Extrapolating from personal experience, I believe fewer surprises would result from keeping one global default connection than buffer-local slime connections.
The one scope of confusion in this mode of operation is when the default connection disappears and the user is for some reason not aware of that fact. In the past the global default connection was automatically changed to the next connection. This could be made explicit involving user prompting so the user is aware that the global default has changed. [This would be no problem because SLIME is not shy in prompting the user for input regarding connections in all other scenarios]
-- Madhu
-
Helmut Eller -
Knut Olav Bøhmer -
Madhu -
Roman Budzianowski -
Stas Boukarev -
Tobias C. Rittweiler