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

[martin rudalics <rudalics@gmx.at>]

 > 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