emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: address@hidden: mouse-autoselect-window needs a delay]


From: Chong Yidong
Subject: Re: address@hidden: mouse-autoselect-window needs a delay]
Date: Sat, 24 Jun 2006 19:36:49 -0400
User-agent: Gnus/5.11 (Gnus v5.11) Emacs/22.0.50 (gnu/linux)

Richard Stallman <address@hidden> writes:

> This complaint seems valid.  Would someone like to address it?

Could we delay this for after the release?  It's far from crucial.

> From: "Marshall, Simon" <address@hidden>
> Subject: mouse-autoselect-window needs a delay
> To: "'Emacs Pretest Bug (address@hidden)'" <address@hidden>
>
> 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.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]