From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: [simon.marshall@misys.com: mouse-autoselect-window needs a delay] Date: Sat, 24 Jun 2006 19:22:51 -0400 Message-ID: Reply-To: rms@gnu.org NNTP-Posting-Host: main.gmane.org Content-Type: text/plain; charset=ISO-8859-15 X-Trace: sea.gmane.org 1151191392 31472 80.91.229.2 (24 Jun 2006 23:23:12 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Sat, 24 Jun 2006 23:23:12 +0000 (UTC) Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jun 25 01:23:11 2006 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1FuHSz-00025I-RU for ged-emacs-devel@m.gmane.org; Sun, 25 Jun 2006 01:23:06 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FuHSz-0002ka-6u for ged-emacs-devel@m.gmane.org; Sat, 24 Jun 2006 19:23:05 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1FuHSn-0002jK-1m for emacs-devel@gnu.org; Sat, 24 Jun 2006 19:22:53 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1FuHSm-0002j8-Lc for emacs-devel@gnu.org; Sat, 24 Jun 2006 19:22:52 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1FuHSm-0002j5-F9 for emacs-devel@gnu.org; Sat, 24 Jun 2006 19:22:52 -0400 Original-Received: from [199.232.76.164] (helo=fencepost.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.52) id 1FuHeJ-0005VY-0V for emacs-devel@gnu.org; Sat, 24 Jun 2006 19:34:47 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.34) id 1FuHSl-0003JN-M9; Sat, 24 Jun 2006 19:22:51 -0400 Original-To: emacs-devel@gnu.org X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:56153 Archived-At: This complaint seems valid. Would someone like to address it? ------- Start of forwarded message ------- From: "Marshall, Simon" To: "'Emacs Pretest Bug (emacs-pretest-bug@gnu.org)'" 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 mouse-autoselect-window needs a delay

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=3D/rvcarma/marshals/software/slash/usr/local' = '--with-x-toolkit=3Dmotif' 'CFLAGS=3D-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-- - --===============1676529925== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ emacs-pretest-bug mailing list emacs-pretest-bug@gnu.org http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug - --===============1676529925==-- ------- End of forwarded message -------