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: Wed, 27 Aug 2008 10:12:19 +0200

>> So when `display-buffer' has called `pop-up-frame-function' we always
>> anticipate that the new frame is mapped (visible), has got input focus,
>> and is raised.
[...]
> In other words, we don't even know that the frame is mapped!]
>
> However, even documenting that the input focus is unspecified would be
> of some use.

Yes.  Nevertheless, the idea that we "anticipate" the window manager to
do all these things is valid I presume - even it we don't "know" whether
the frame is visible in the first place.

>>  IIUC we currently rely on the window-manager to
>> raise and focus the frame.
>
> Currently Emacs does both.  Requesting the focus from the X server
> (XSetInputFocus) and telling the window manager to activate
> (x_ewmh_activate_frame [which for most WMs is focus+raise]) the frame.

I suppose we do both just because up to Emacs 22 we used XSetInputFocus
exclusively and maybe some window managers won't handle EWMHs yet (or
won't handle them in the sense of Emacs).  Should we, in your opinion
make this customizable?  That is, an option `frame-activate-method'
which if nil does both (as now), if 'explicit does XSetInputFocus only,
and if 'implicit does x_ewmh_activate_frame only?.

> I guess the usual sequence of events is this:
>
> 1. Emacs tries to map a frame and waits for notification
> 2. WM intercepts map request
> 3. WM maps the frame + gives focus to frame + raises frame
> 4. Emacs receives MapNotify
>
> If we add a fifth step:
>
> 5. Emacs requests focus and informs WM to activate the frame

.... without waiting for a FocusIn event?

> we probably do something twice, but activating the same frame twice
> shouldn't hurt.  We have a problem if the WM decides to activate a
> different frame, but that seems unlikely.

IIRC window managers relying on EWMHs do not like explicit focus and
raise frame requests.  They might do something with such requests but
this something could be quite unpredictable.  I also STR that people
reported some flickering with two subsequent raise or focus requests.
Hence, once again: Should we try - with the help of an option - do this
either the old-style way without calling window-manager hints or do it
new-style with such hints and possibly waiting for a FocusIn event?

>> Note that `x-focus-frame' uses XSetInputFocus together with
>> x_ewmh_activate_frame.  This mixture seems slightly frightening.
>
> Yes, this looks like "programming by accident".

... rather "better safe than sorry".

>> Does it do so even with `focus-follows-mouse' nil?
>
> select-frame-set-input-focus seems to work identical for
> focus-follows-mouse and click-to-focus mode.  The frame receives the
> input focus, is raised, and the mouse pointer is moved to its upper
> right corner.

Ahhh no, this time I meant the Emacs option `focus-follows-mouse'.
`select-frame-set-input-focus' moves the mouse iff that is non-nil.

>> (defcustom pop-up-frame-activate nil
>>   "When non-nil try to explicitly activate popped up frames.
>> If this is nil leave it to Emacs how to activate the frame.  If
>> this is t always try to activate a new frame.  Anything else
>> means activate a frame if and only if it existed before the most
>> recent call to `display-buffer' ..."
>>   :type '(choice (const :tag "System Dependent" nil)
>> 		 (const :tag "Existing frames only" 'existing-only)
>> 		 (const :tag "Always" t))
>>   :group 'frames)
>
> I'm not sure that this issue must be customizable at all.  As a user of
> pop-to-buffer, I don't quite see the usefulness of the "System
> Dependent" and "Existing frames only" choices.  An Emacs implementor
> could argue that "System Dependent" is simpler to implement, but if the
> more complicated variants are implemented too it's no longer "simpler".

The "System Dependent" choice is necessary to let the current (maybe
faulty for some or many of us) behavior carry over for those who like it
as it is.  The question is whether we want to distinguish the other two.

> I propose this change instead:
[...]
>     (let ((old-frame (selected-frame)))
>       (select-window (display-buffer buffer other-window) norecord)
>       (unless (eq old-frame (selected-frame))
> 	;; select-window doesn't set the input focus.  Set it explicitly.
> 	;; FIXME: select-window should request focus (perhaps lazily).
> 	(select-frame-set-input-focus (select-frame))))
>     buffer))

I suppose you mean

 	(select-frame-set-input-focus (selected-frame))))

here.  This has the drawback that we unconditionally do
`select-frame-set-input-focus' for new frames.  If we decide that this
won't harm ...

My experience is that once in a while some window manager won't get
along with whatever we decide here.  Hence I'd like to put in one or two
options so users can try an alternative without immediately affecting
the behavior of this on other systems.

martin

Previous Next

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