From xemacs-m  Tue Feb  4 17:47:18 1997
Received: from CNRI.Reston.VA.US (CNRI.Reston.VA.US [132.151.1.1])
	by xemacs.org (8.8.5/8.8.5) with SMTP id RAA13581
	for <xemacs-beta@xemacs.org>; Tue, 4 Feb 1997 17:47:12 -0600 (CST)
Received: from newcnri.cnri.reston.va.us by CNRI.Reston.VA.US id aa27496;
          4 Feb 97 18:48 EST
Received: from anthem.CNRI.Reston.Va.US by newcnri.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id SAA09840; Tue, 4 Feb 1997 18:48:26 -0500
Received: by anthem.CNRI.Reston.Va.US (SMI-8.6/SMI-SVR4)
	id SAA23560; Tue, 4 Feb 1997 18:48:25 -0500
Date: Tue, 4 Feb 1997 18:48:25 -0500
Message-Id: <199702042348.SAA23560@anthem.CNRI.Reston.Va.US>
From: "Barry A. Warsaw" <bwarsaw@anthem.cnri.reston.va.us>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit
To: Steven L Baur <steve@miranova.com>
Cc: xemacs-beta@xemacs.org
Subject: Re: Keyboard focus policy (was Re: 19.15b92 - Pure storage exhausted)
References: <199702040556.WAA07410@branagh.ta52.lanl.gov>
	<m2pvyh9jnr.fsf@altair.xemacs.org>
	<199702042037.NAA12497@branagh.ta52.lanl.gov>
	<199702042147.OAA14285@branagh.ta52.lanl.gov>
	<kig3evcgq5g.fsf@jagor.srce.hr>
	<m2wwsow531.fsf_-_@altair.xemacs.org>
Reply-To: "Barry A. Warsaw" <bwarsaw@CNRI.Reston.VA.US>
X-Attribution: BAW
X-Oblique-Strategy: Courage!
X-WWW-Homepage: http://www.python.org/~bwarsaw


>>>>> "sb" == Steven L Baur <steve@miranova.com> writes:

    sb> With a focus-follows-mouse policy, an application like XEmacs
    sb> should *never* redirect keyboard focus to a window other than
    sb> the one under the mouse.

I can appreciate it's a *really* tricky thing to get right.  The fact
that XEmacs has always had interaction problems with focus is
testament to this.

Just as an extra data point, I'm a rabid anti-mouser (hmm glad my
cat's not :-) and I normally run with two XEmacs frames side by side.
I can just fit them on one screen, with a minimal wide scrollbar and
window decorations.  I like never having to touch the mouse to start
editing in the left frame, or then subsequently switch to the right
frame.  Well almost never, since occasionally XEmacs gets confused and
won't throw focus to one of its other windows.  It won't DWIM! :-)
Well, that's not entirely accurate.  It throws focus so that
subsequent commands affect the desired frame, but the cursor often
remains hollow and the WM (Fvwm 2.0.43) has no idea the focus was
throw, so that the window decoration is bland-I-don't-have-focus.

Hmm, what would I like it to do?  I guess I'd want a command that will
let me throw focus to any uniconified, visible window on the current
device.  Actually, for a dual-headed X arrangement (which I use), I'd
also like to be able to throw focus to an uniconified, visible window
on either screen of the current display.  Believe it or not, this does
sort of work, although as above, the cursor stays hollow and the WM
doesn't update the decorations.

While I'm ranting :-) one other nit.  The minibuffer on the second
screen's frame always mirrors the minibuffer on any frame in the first
screen.  This lack of cues makes it very difficult to know which frame
is going to get the next key I type.

All in all, XEmacs does pretty well though.  At least well enough for
me not to put my money where my mouth is. :-)

-Barry

