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

[Helmut Eller]

* martin rudalics [2008-08-27 10:12+0200] writes:

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

A way to call one of XSetInputFocus or x_ewmh_activate_frame without
calling the other would be useful for experimentation.  But I think that
few people will use/need that.  So, no, it shouldn't be customizable.


It think it would be nice (but not worth to implement) if Emacs could be
customized with two "focus models":

 1. Let the window manager do all the focus handling.  This is similar
    to what Emacs does currently.  In this model Emacs should use
    x_ewmh_activate_frame without XSetInputFocus [I think that this would 
    avoid some race conditions].  pop-to-buffer could
    still "activate" the frame, but it would be merely a hint and no
    guarantee.  Creating frames which aren't focused initially is
    probably hard(er) in this model.

 2. Emacs does its own focus management.  In this model, Emacs should
    clear the input flag in WM_HINTS, handle WM_TAKE_FOCUS events, and
    explicitly call XSetInputFocus.  A reasonable window manager will
    handle FocusIn events to decorate the focused frame appropriately.
    Since the input flag is cleared, the WM shouldn't focus new frames.
    [This model may be incompatible with toolkits, like GTK.]

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

Yes, without waiting.  If we call

  (select-frame-set-input-focus (window-frame (display-buffer ...)))

we don't wait for FocusIn.

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

Since we don't have a window manager which causes trouble, we can't even
test whether the change makes any difference.  Let's wait until somebody
reports actual problems :-)

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

I read to fast :-)  No with focus-follows-mouse=nil the mouse pointer
doesn't move but the other frame receives the input focus.

>>> (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 think that, if "System Dependent" stays the default, then few people
will profit from the other choices, simply because few people take the
time to customize it.  Despite that, I think that very few people prefer
the current behavior.

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

Yes, you are right.

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

Most of the time it will work flawlessly on new frames.  What's the
worst that could happen?  Some flickering.  I think that we can live
with that imperfection.

Helmut.