GNU bug report logs - #23478
25.0.93; Mouse region selection asymmetry

Previous Next

Full log

View this message in rfc822 format

From: Stephen Berman <stephen.berman <at> gmx.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 23478 <at> debbugs.gnu.org
Subject: bug#23478: 25.0.93; Mouse region selection asymmetry
Date: Sun, 08 May 2016 21:41:19 +0200

On Sun, 08 May 2016 21:54:17 +0300 Eli Zaretskii <eliz <at> gnu.org> wrote:

>> From: Stephen Berman <stephen.berman <at> gmx.net>
>> Cc: 23478 <at> debbugs.gnu.org
>> Date: Sun, 08 May 2016 20:31:04 +0200
>> 
>> > I don't think calling 'recenter' is TRT.  First, the fact that you see
>> > the display recentering after item 3 in your recipe is only the
>> > default behavior; if you set scroll-conservatively to 101 before
>> > repeating your recipe, you will see that Emacs instead scrolls the
>> > display just one line, i.e. the minimum amount required to bring point
>> > back into view.  Users that set scroll-conservatively like that will
>> > lynch us if we recenter display in this situation.
>> 
>> Good point, I think I had that vaguely in mind when I expressed my
>> doubts about `recenter', but couldn't remember just what needed to be
>> taken account of.  I did try an alternative to `recenter', using
>> `goto-char' instead, which changes point and hence induces recentering
>> by redisplay, but it also loses the region highlighting.  I tried (with
>> several variants involving redisplay-highlight-region-function and
>> redisplay--update-region-highlight) but failed to figure out how to keep
>> the highlighting, but if that's a better way to handle this, maybe
>> someone more familiar with the region highlighting code will be able to
>> do that.
>> 
>> > Bottom line, I don't think we should behave like that by default.  I
>> > think this could be an optional feature, but it must obey
>> > scroll-conservatively (and maybe also other related variables).
>> 
>> Definitely.  Thanks for the feedback.
>
> How about momentarily exchanging mark and point, then calling sit-for
> for some small time interval, then exchanging back?  Shouldn't this do
> what you want, or at least come close?

I didn't think of that, but it looks like it does the trick.  It also
behaves well with scroll-conservatively.  Thanks!  Do you really think
this should be conditioned by a user option?  I'd be surprised if some
people prefer the existing behavior or there's any code that relies on
it.  Can you think of any gotchas?

Steve Berman

diff --git a/lisp/mouse.el b/lisp/mouse.el
index fa355ff..d256393 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -531,7 +531,12 @@ mouse-set-point
   (interactive "e\np")
   (mouse-minibuffer-check event)
   (if (and promote-to-region (> (event-click-count event) 1))
-      (mouse-set-region event)
+      (progn
+        (mouse-set-region event)
+        (when (> (window-start) (region-beginning))
+	  (exchange-point-and-mark)
+	  (sit-for 0.01)
+	  (exchange-point-and-mark)))
     ;; Use event-end in case called from mouse-drag-region.
     ;; If EVENT is a click, event-end and event-start give same value.
     (posn-set-point (event-end event))))

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.