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

[martin rudalics]

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

I'm afraid that we fix this just for the platforms we use.  If someone
reports a breakage of this on another platform before the release we
might be able to fix it there as well.  Otherwise this will go the way
of most "fixes" in this department.

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

We agreed that the latter isn't realistic anyway.

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

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

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

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

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

Maybe there's more than just some imperfection.

martin