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: Sat, 23 Aug 2008 14:05:58 +0200

> The problematic cases are
>
>   (let ((pop-up-frames t)) (display-buffer ...))
>
> for display-buffer, if the buffer was not visible before.  In this case
> a new frame appears, which (wrongly) has the input focus.

Rather "which (wrongly) has the input focus for window managers able to
handle mapping a new frame without giving input focus to it" because
IIUC with certain settings (focus-follows-mouse) some window managers
automatically do give focus to the new frame.  I also suppose that the
only means to take focus away from the new frame is by giving focus to
the previously selected frame (though we can't even be sure that frame
had focus or was risen).

> (If the
> buffer is already visible in some frame, that frame is raised but the
> focus is not moved to that frame.  This is IMO correct.)

I think so.  But what happens in the `pop-to-buffer' case when a _new_
frame gets displayed.  Should we give it input-focus?  I suppose so from
your situation B comments below.  So in all cases where situation A has
Y (that is `display-buffer' fails TDTRT) `pop-to-buffer' DTRT?

> For pop-to-buffer:
>
>   (let ((display-buffer-reuse-frames t)) (pop-to-buffer ...))
>
> if the buffer is already visible in a frame which has not the input
> focus.  This should move input focus to that frame, but it currently
> doesn't.  (If the frame has already the focus, pop-to-buffer works as it
> should.)

Do we agree on the general rule that

- `display-buffer' should never try to move input focus to another (new
  or existing) frame, while

- `pop-to-buffer' should try to give input focus to the frame where
  BUFFER is displayed (this could be the selected frame as well).

> Let's call the display-buffer case, situation A and the pop-to-buffer
> case, situation B.
[...]
> OK, here is what I see:
>
> A  B  WM         WM focus mode
> ---------------------------------------
> Y  N  Sawfish    follow-mouse (enter-only + focus-window-when-mapped)
> N  N  Sawfish    follow-mouse (enter-only + !focus-window-when-mapped)
> Y  N  Sawfish    follow-mouse (enter-exit + focus-window-when-mapped)
> N  N  Sawfish    follow-mouse (enter-exit + !focus-window-when-mapped)
> Y  N  Sawfish    click-to-focus (click + focus-window-when-mapped)
> N  N  Sawfish    click-to-focus (click + !focus-window-when-mapped)
> Y  N  Sawfish    click-to-focus (click + focus-window-when-mapped + focus-click-through)
> N  N  Sawfish    click-to-focus (click + !focus-window-when-mapped + focus-click-through)

I'm completely ignorant WRT to focus-window-when-mapped: Does this mean
that a window that is not risen can get focus?  Note in this context
that `select-frame-set-input-focus' always raises the frame.

> ?  N  Metacity   follow-mouse (mouse)
> ?  N  Metacity   follow-mouse (sloppy)
> ?  N  Metacity   click-to-focus (click)

Does Metacity respect `select-frame-set-input-focus' at all?

> Y  N  KWin       follow-mouse
> Y  N  KWin       click-to-focus
> Y  M  FluxBox    follow-mouse (Sloppy Focus)
> Y  M  FluxBox    follow-mouse (Auto Raise)

For the M cases `raise-frame' could move the mouse pointer to that frame
which seems to call for yet another option.

> Y  N  FluxBox    click-to-focus
> Y  Y  IceWM      click-to-focus

So IceWM is the only window manager to handle situation B.  IIUC it does
so because do_switch-frame manages to get Fredirect_frame_focus through
to redirect input to that frame.  Or do you have another explanation?
Could you try to GDB do_switch_frame for IceWM and one of the others to
see they do differently?

> Y  N  Twm        follow-mouse (new frames need mouse click for placement)
>
> A and B are the scenarios described above.
> Y means: Yes, does switch focus.
> N means: No, doesn't switch focus.
> ? means: sometimes (probably depending on mouse and window positions)
> M means: No, doesn't switch focus, except when raising the frame
>          also moves the mouse pointer into the frame.
>
> I set Emacs' focus-follows-mouse according to the WM focus mode (except
> when I forgot it :-)
>
> The Ys for Sawfish are apparently directly related to the
> focus-window-when-mapped option.  So, it's probably not Emacs that
> switches the focus in the A scenario, but the window managers.

Can we conclucde that the other window managers implicitly focus a frame
when mapping it?

> The docstring for select-window could perhaps
> also state a bit more prominently that the "selected window" and the
> "input focus" are different things

... if the implementation is bogus this will hardly help ...

> or at least refer to
> select-frame-set-input-focus.

That function lumps together too many things.  At least `raise-frame'
should probably be optional there.

> BTW, below is a proof of concept implementation for the
> update-focus-lazily idea.

Would this work with `redirect-frame-focus'?  I haven't studied it in
detail.

martin

Previous Next

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