bug#745: pop-to-buffer, frames, and input focus

[Helmut Eller <eller.helmut@gmail.com>]

* martin rudalics [2008-08-20 16:50+0200] writes:

>> Pops up two frames, one frame displays the "foo" buffer and the other
>> the "*scratch*" buffer (so far so good).  But the "foo" frame has not
>> the input focus.  Isn't pop-to-buffer supposed to switch input focus
>> too?
>
>      (select-frame-set-input-focus frame))
>
> gives input focus to the previously selected frame.

Are you saying, that pop-to-buffer can't be used to select the window,
the frame, and input focus at the same time?  If so, when should
pop-to-buffer be used?  Aren't that unusual situations when
pop-to-buffer should not also select the input focus?

If you have any hints or guidelines how be a good buffer/window/frame
citizen in different scenarios, that would be much appreciated.

I'm not using multiple frames myself, but I'm maintaining a package
called SLIME[*] which is used by a number of people who use frames.  I'm
not excited at all about rewriting a dozen or so uses of pop-to-buffer
just to support multiple frames.  There are some variables like
display-buffer-reuse-frames and special-display-buffer-names and I hoped
that those variables were supposed to make it easy to support multiple
frames without cluttering the source code.

[*] http://www.common-lisp.net/project/slime/

>
>> Also note that I had to save and restore the selected frame
>> around display-buffer.  If I try
>>
>>   emacs -Q --eval '(let ((pop-up-frames t))
>>                      (display-buffer (get-buffer-create "foo")))'
>>
>> the "foo" buffer is selected, even though display-buffer should not
>> switch the selected window.
>
> I'm not sure whether on some system there were problems when raising a
> frame and/or giving it input focus, and not selecting it.  At least with
> Emacs 22 the frame was selected already.  Since there's only one window
> on the new frame, that window must be selected as well.
>
> In any case you're right: either the window must not be selected or the
> documentation should tell when and why it selects the window.

The docstring of display-buffer reads
"Make buffer BUFFER-OR-NAME appear in some window but don't select it. ..."
I think it be would less surprising if the input focus would not be switched
to the new frame.

>> Not even save-window-excursion stops display-buffer from switching the
>> frame:
>>
>>   emacs -Q --eval '(save-window-excursion
>>                      (let ((pop-up-frames t))
>>                         (display-buffer (get-buffer-create "foo"))))'
>
> `save-window-excursion' is of no use here: It permits you to change the
> contents of a frame in the body and restore the initial contents
> afterwards.  You do that with the originally selected frame here.  The
> new frame created by `display-buffer' is not affected by this.

save-window-excursion is supposed to "... Also restore the choice of
selected window. ..."

If I do

   emacs -Q -nw --eval '(save-window-excursion
                          (let ((pop-up-frames t))
                            (display-buffer (get-buffer-create "foo"))))'

I end up in the "*scratch*" buffer not in "foo".  It would be more
consistent if the X11 version and the tty version would restore the
input focus to the same frame.  The tty version is the behavior that I
would expect.

Helmut.