[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 <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: 23478@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))))