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

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

* martin rudalics [2008-08-20 22:56+0200] writes:

>> 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?
>
> With emacs -Q evaluating
>
> (let ((pop-up-frames t)
>       (buffer (get-buffer-create "foo")))
>   (pop-to-buffer buffer))
>
> here gets me a new frame on top of the previously selected one, the
> window displaying buffer `foo' is the selected window, and when I now
> start typing, characters get displayed in that window.  What did you
> expect and what did you get?

Consider my original example:

(progn
  (let ((frame (selected-frame))
        (pop-up-frames t))
    (display-buffer (get-buffer-create "foo"))
    (select-frame-set-input-focus frame))
  
  (let ((display-buffer-reuse-frames t))
    (pop-to-buffer "foo")))

First, display-buffer is just used to create two frames.  This switches
(surprisingly) focus to the "foo" buffer.  select-frame-set-input-focus
is used to force the focus back to the "*scratch*" buffer.  Then we use
pop-to-buffer, but the input focus remains (surprisingly) in the
"*scratch*" buffer.

I expect this:

  pop-to-buffer     should switch the input focus
  display-buffer    should not change 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 slightly confused because in your earlier scenario you bemoaned the
> fact that the frame _was_ selected.  All I wanted to say that raising a
> frame, giving it input focus, and _not_ selecting it might be difficult.

I see.  But this is also not what I expect.

>> 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/
>
> I moved `pop-to-buffer' to window.el so you can easier try to play
> around with it and propose a solution that fits your needs ;-)

Thanks for the moving it :-)

pop-to-buffer is more or less (select-window (display-buffer ...)).
This looks very reasonable, but it doesn't transfer the input focus.
(under X; in a tty everything works well.)

On the other hand, display-buffer switches sometimes (when a new frame
is created) the input focus, even when that was not asked for.

Maybe pop-to-buffer could do something like 

  (let ((window (display-buffer ...)))
    (select-window window)
    (select-frame-set-input-focus (window-frame window)))

That would solve my immediate problem, but I suspect that select-window
should be smarter.  My naive interpretation of select-window's C source
is that select-window tries to select the frame.  But apparently forgets
about the input focus.  This may also be the reason why
save-window-excursion doesn't restore the input focus.

Selecting a window, without giving it the input focus is probably rarely
needed.  Perhaps select-window should transfer the input focus by
default.

Helmut.