Hi,
I'd like to propose instead of creating the buffers in the continuation thunk of slime-eval-async to create and pop them up before doing the RPC. The continuation should merely insert the result of the RPC.
And the continuation should not steal my input focus.
I think the unpredictable buffer popping and input stealing annoys more people than me. I know it requires major changes, and I won't have time doing it myself for the time being, but perhaps someone else steps up.
-T.
* Tobias C. Rittweiler [2009-01-05 11:57+0100] writes:
Hi,
I'd like to propose instead of creating the buffers in the continuation thunk of slime-eval-async to create and pop them up before doing the RPC. The continuation should merely insert the result of the RPC.
And the continuation should not steal my input focus.
I think the unpredictable buffer popping and input stealing annoys more people than me. I know it requires major changes, and I won't have time doing it myself for the time being, but perhaps someone else steps up.
I think you are lumping together a few things here. Displaying buffers and switching focus has not much to do with slime-eval-async.
Often the result of the RPC is needed before we can decide to create a new buffer (unless we add a time travel feature). E.g M-. only creates a buffer if there is more than one possible definition.
I figure you bring up this issue because C-c C-c and friends pops up a buffer much more often then it used to. Yes, that's annoying.
The reason to display the buffer with the compiler messages at all was that some messages are not associated with a source-location and are therefore not annotated in the source buffer. E.g. calling a undefined function FOO causes two messages:
/tmp/x.lisp:3:3: style-warning: undefined function: FOO style-warning: This function is undefined: FOO
The second message has no source-location. This is arguably a flaw in the backend (and in the compiler: the second message is redundant). Perhaps we should never display that buffer and if a user wants to see it she can create it with M-x slime-show-compilation-log.
To display the buffer before the compilation starts would probably be just as annoying for C-c C-c as is displaying it afterwards.
The compilation log buffer should probably not be selected automatically, especially not for C-c C-c.
There are a few more situations when popup buffers don't need to receive focus: documentation commands, apropos etc. It would even be more consistent with Emacs' builtin apropos which doesn't select the apropos window (OTOH XEmacs selects it). It would also save us the trouble of restoring the window configuration, because C-x 1 would then be used to "close" the other window and 'q' could just bury the buffer.
Helmut.
Helmut Eller heller@common-lisp.net writes:
I think you are lumping together a few things here. Displaying buffers and switching focus has not much to do with slime-eval-async.
They are related in so far as I'm mostly referring to popping up buffers after some delay (i.e. after an async request returned from SWANK.)
I.e. I may want to C-c C-k --- which may take a short moment of time to complete --, but I'd also like to do something in the meantime like switching between Emacs frames. I still want the compilation notes buffer be popped up in the frame I issued C-c C-k in.
Often the result of the RPC is needed before we can decide to create a new buffer (unless we add a time travel feature). E.g M-. only creates a buffer if there is more than one possible definition.
Well, M-. is done by a synchroneous request, so Emacs blocks and I can't do anything in the meantime.
I figure you bring up this issue because C-c C-c and friends pops up a buffer much more often then it used to. Yes, that's annoying.
Yes, that's true, too. But C-c C-c is most often instantanenous so it's not that bad because I'm not tempted to do anything in between.
Another scheme would be to _never_ pop up a new buffer, but introduce a keybinding like C-c C-z which pops up the buffer created by the last command, perhaps in a stack-like manner. A command which created a new buffer in the background says so in the minibuffer.
-T.
-
Helmut Eller -
Tobias C. Rittweiler