[slime-devel] [RfC] popping buffers up asyncly

[Helmut Eller]

* 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.