[Top][All Lists]

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

bug#23478: 25.0.93; Mouse region selection asymmetry

From: Stephen Berman
Subject: bug#23478: 25.0.93; Mouse region selection asymmetry
Date: Sun, 08 May 2016 21:41:19 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.93 (gnu/linux)

On Sun, 08 May 2016 21:54:17 +0300 Eli Zaretskii <address@hidden> wrote:

>> From: Stephen Berman <address@hidden>
>> Cc: address@hidden
>> 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))))

reply via email to

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