[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
address@hidden: mouse-autoselect-window needs a delay]
|
From: |
Richard Stallman |
|
Subject: |
address@hidden: mouse-autoselect-window needs a delay] |
|
Date: |
Sat, 24 Jun 2006 19:22:51 -0400 |
This complaint seems valid. Would someone like to address it?
------- Start of forwarded message -------
From: "Marshall, Simon" <address@hidden>
To: "'Emacs Pretest Bug (address@hidden)'"
<address@hidden>
Date: Wed, 21 Jun 2006 15:19:57 +0100
MIME-Version: 1.0
Subject: mouse-autoselect-window needs a delay
Content-Type: multipart/mixed; boundary="===============1676529925=="
X-Spam-Status: No, score=0.1 required=5.0 tests=HTML_30_40,HTML_MESSAGE
autolearn=failed version=3.0.4
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
- --===============1676529925==
Content-Type: multipart/alternative;
boundary="----_=_NextPart_001_01C6953D.C5C1E480"
This message is in MIME format. Since your mail reader does not understand
this format, some or all of this message may not be legible.
- ------_=_NextPart_001_01C6953D.C5C1E480
Content-Type: text/plain
This isn't a bug as such, but a suggestion for feature refinement.
I like the concept of mouse-autoselect-window, since it allows me to attempt
to mimic my WM's focus-follows-mouse frame policy for Emacs windows. But
there's always a but.
If you have a split window but the invocation of a command forces you to
move the mouse across a different window, you will probably end up applying
the command to the wrong window. For example, suppose a frame shows 2
different windows, each containing a different C buffer. Suppose you want
to comment out a region in the buffer in the lower window. You select the
region, move the mouse up to the menu bar, select C > Comment Out Region,
and watch in frustration as the operation is performed on the buffer in the
upper window. The focus had changed as you moved to the menu bar.
WMs that support focus-follows-mouse together with raise-on-focus have a
similar issue. (Focus-follows-mouse is probably best with raise-on-focus.)
They typically deal with that issue by (a) having a delay, (b) requiring the
mouse to be stationary, or (c) both, before transferring focus and raising.
That way, focus is less likely to be transferred when the user does not wish
it. My current WM implements (a) with something like a 0.5s delay.
So, I'm suggesting that (a) and/or (b) be implemented for
mouse-autoselect-window. Perhaps the variable could have a numeric value,
meaning a delay. A value of t might be equivalent to a value of 0. A
mouse-[123] in a window would still immediately change focus.
Comments? Simon.
In GNU Emacs 22.0.50.1 (sparc-sun-solaris2.8, Motif Version 2.1.0)
of 2006-06-15 on perth
X server distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure
'--prefix=/rvcarma/marshals/software/slash/usr/local'
'--with-x-toolkit=motif' 'CFLAGS=-g''
Important settings:
value of $LC_ALL: nil
value of $LC_COLLATE: en_GB.ISO8859-1
value of $LC_CTYPE: en_GB.ISO8859-1
value of $LC_MESSAGES: C
value of $LC_MONETARY: en_GB.ISO8859-1
value of $LC_NUMERIC: en_GB.ISO8859-1
value of $LC_TIME: en_GB.ISO8859-1
value of $LANG: en_GB.ISO8859-1
locale-coding-system: iso-8859-1
default-enable-multibyte-characters: t
- ------_=_NextPart_001_01C6953D.C5C1E480
Content-Type: text/html
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; =
charset=3Dus-ascii">
<META NAME=3D"Generator" CONTENT=3D"MS Exchange Server version =
5.5.2658.24">
<TITLE>mouse-autoselect-window needs a delay</TITLE>
</HEAD>
<BODY>
<P><FONT SIZE=3D2 FACE=3D"Arial">This isn't a bug as such, but a =
suggestion for feature refinement.</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">I like the concept of =
mouse-autoselect-window, since it allows me to attempt to mimic my WM's =
focus-follows-mouse frame policy for Emacs windows. But there's =
always a but.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">If you have a split window but the =
invocation of a command forces you to move the mouse across a different =
window, you will probably end up applying the command to the wrong =
window. For example, suppose a frame shows 2 different windows, =
each containing a different C buffer. Suppose you want to comment =
out a region in the buffer in the lower window. You select the =
region, move the mouse up to the menu bar, select C > Comment Out =
Region, and watch in frustration as the operation is performed on the =
buffer in the upper window. The focus had changed as you moved to =
the menu bar.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">WMs that support focus-follows-mouse =
together with raise-on-focus have a similar issue. =
(Focus-follows-mouse is probably best with raise-on-focus.) They =
typically deal with that issue by (a) having a delay, (b) requiring the =
mouse to be stationary, or (c) both, before transferring focus and =
raising. That way, focus is less likely to be transferred when =
the user does not wish it. My current WM implements (a) with =
something like a 0.5s delay.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">So, I'm suggesting that (a) and/or (b) =
be implemented for mouse-autoselect-window. Perhaps the variable =
could have a numeric value, meaning a delay. A value of t might =
be equivalent to a value of 0. A mouse-[123] in a window would =
still immediately change focus.</FONT></P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Comments? Simon.</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">In GNU Emacs 22.0.50.1 =
(sparc-sun-solaris2.8, Motif Version 2.1.0)</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> of 2006-06-15 on perth</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">X server distributor `Hummingbird =
Ltd.', version 11.0.100015</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial">configured using `configure =
'--prefix=3D/rvcarma/marshals/software/slash/usr/local' =
'--with-x-toolkit=3Dmotif' 'CFLAGS=3D-g''</FONT>
</P>
<P><FONT SIZE=3D2 FACE=3D"Arial">Important settings:</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> value of $LC_ALL: nil</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> value of $LC_COLLATE: =
en_GB.ISO8859-1</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> value of $LC_CTYPE: =
en_GB.ISO8859-1</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> value of $LC_MESSAGES: =
C</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> value of $LC_MONETARY: =
en_GB.ISO8859-1</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> value of $LC_NUMERIC: =
en_GB.ISO8859-1</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> value of $LC_TIME: =
en_GB.ISO8859-1</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> value of $LANG: =
en_GB.ISO8859-1</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> locale-coding-system: =
iso-8859-1</FONT>
<BR><FONT SIZE=3D2 FACE=3D"Arial"> =
default-enable-multibyte-characters: t</FONT>
</P>
</BODY>
</HTML>
- ------_=_NextPart_001_01C6953D.C5C1E480--
- --===============1676529925==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
emacs-pretest-bug mailing list
address@hidden
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
- --===============1676529925==--
------- End of forwarded message -------