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

[Helmut Eller]

* martin rudalics [2008-08-28 13:46+0200] writes:

>>  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.]
>
> And why do you think this not worth implementing?

This takes more than a few hours of hacking.  At least a few days, more
likely a few weeks.  That's to much time for such a minor nicety.

Improving select-window so that it request input focus (somewhat
efficiently) would be more worthwhile.

>> Yes, without waiting.  If we call
>>
>>   (select-frame-set-input-focus (window-frame (display-buffer ...)))
>>
>> we don't wait for FocusIn.
>
> Is there a place where Emacs _should_ wait for a FocusIn?

No.  select-frame-set-input-focus seems to be the only focus related
function (despite x-focus-frame which is presumably internal).  If we
interpret select-frame-set-input-focus as "request input focus" and not
as "request input focus and wait until we know that we actually have the
focus" then we don't need to wait.  IMO, the former interpretation is
consistent with the usual assumption that Emacs updates the display
"later" or at least not in lock step with Lisp code.

>> 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 :-)
>
> You've read some of the earlier threads - and there's a lot more of
> these (some of them related to frame resizing).  We do have to
> anticipate such problems now: People usually don't go through the
> troubles testing this with any window-manager but their own.

I know about the following problems:

 1. pop-to-buffer doesn't switch input focus
 2. select-window doesn't switch input focus
 3. x-create-frame does switch input focus (with most WMs)

Is there something else?  

We agreed that we wont fix 3.  

1 would be fixed by calling select-frame-set-input-focus in
pop-to-buffer (either customizable or not).  Do we need to test
something?

Fixing 2 isn't so clear.  This was shortly discussed on the mailing list
but RMS said, at that time, that more important things should be done.


>> 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.
>
> But if they complain we can give them an option to test.

It would be reasonable to minimize the number of people who need to
change the defaults.

>> Despite that, I think that very few people prefer the current
>> behavior.
>
> It's not a question of preference.  It might simply work for them.  So
> let's not cause unwanted breakage.

Some people, like me, who do actually care, also like to keep the code
readable, simple, and predictable.  New customization options cost a lot
in terms of readability.

Helmut.