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

[martin rudalics]

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

Ahhh, I can't reproduce that.  Evaluating your `progn' moves focus to
the `foo' buffer here (with emacs -Q).  So it seems we have a platform
(maybe window manager) specific problem.

> I expect this:
>
>   pop-to-buffer     should switch the input focus
>   display-buffer    should not change the input focus

`pop-to-buffer' has the sole additional twist WRT `display-buffer':

    (select-window (display-buffer buffer other-window) norecord)

That is, the window used by `display-buffer' should get definitively
selected.  So, if `display-buffer' has decided to use "another" frame,
raising that frame, giving it input focus, and implicitly selecting that
frame and the window used for displaying the buffer_must_ have been
already handled by `display-buffer'.  In this case, the `select-window'
done by `pop-to-buffer' looks like a NOOP though I didn't verify that.

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

So `pop-to-buffer' raising a frame + giving it input focus + selecting
it is always OK with you?

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

Does it solve all your problems in this context?  I suppose it won't be
of any help when you use `display-buffer' with `pop-up-frames' t :-(

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

I suppose we can't do that.  `select-window' is frequently used to
temporarily switch to another window (compare `save-selected-window').
Shifting input focus to another frame and possibly back to the initial
frame might confuse the window manager.

martin