Re: select-window focus problem [was: Re: minor compile.el bug]
Glynn Clements <glynn(a)sensei.co.uk> writes:
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?
Probably. Also, it is sometimes useful. I suggest the following:
keep the behaviour of `C-x 5 o' independent of focus-follows-mouse
(implement it by binding `focus-follows-mouse' to nil within the
function), and document that `other-frame' is non-ICCCM compliant.
The lucky thing with `C-x 5 o' is that you can't really press it "by
mistake", nor can XEmacs activate it for you. If you press that
mouthful, you probably know what you want to get, and XEmacs should
give it to you.
--
Hrvoje Niksic <hniksic(a)srce.hr> | Student at FER Zagreb, Croatia
--------------------------------+--------------------------------
Satellite Safety Tip #14:
If you see a bright streak in the sky coming at you, duck.