Re: select-window focus problem [was: Re: minor compile.el bug]
Hrvoje Niksic wrote:
Maybe someone who knows X should look at it and comment? Glynn,
maybe?
What, Me?
Hmm, I guess at better have a look at the ICCCM then.
4.2.7. Input Focus
Clients can request notification that they have the input
focus by selecting for FocusChange events on their top-level
windows; they will receive FocusIn and FocusOut events.
Clients that need to set the input focus to one of their
subwindows should not do so unless they have set
WM_TAKE_FOCUS in their WM_PROTOCOLS property and have done
one of the following:
Set the input field of WM_HINTS to True and actually
have the input focus in one of their top-level windows
Set the input field of WM_HINTS to False and have
received a suitable event as described in section 4.1.7
Have received a WM_TAKE_FOCUS message as described in
section 4.1.7
This seems to be the usual `applications should confine themselves to
their own window' rule. From reading the docstring of
focus-follows-mouse, I would guess that it probably needs to be
non-nil for ICCCM-compliant behaviour.
Switching focus between frames (top-level windows) is something that
is usually considered to be the WMs job, so the question probably
isn't `how should C-x 5 o behave?' but `should it exist at all?'.
What is the motivation for `other-frame'? Is it an attempt to get
around twm's rigid focus-follows-mouse policy?
--
Glynn Clements <glynn(a)sensei.co.uk>