GNU bug report logs - #745
pop-to-buffer, frames, and input focus

Previous Next

Full log

View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Helmut Eller <eller.helmut <at> gmail.com>
Cc: 745 <at> debbugs.gnu.org
Subject: bug#745: pop-to-buffer, frames, and input focus
Date: Thu, 21 Aug 2008 11:04:53 +0200

> 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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.