From: Stephen Berman <stephen.berman@gmx.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: 23478@debbugs.gnu.org
Subject: bug#23478: 25.0.93; Mouse region selection asymmetry
Date: Sun, 08 May 2016 21:41:19 +0200 [thread overview]
Message-ID: <87shxswd5s.fsf@gmx.net> (raw)
In-Reply-To: <8360uoe5ye.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 08 May 2016 21:54:17 +0300")
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))))
next prev parent reply other threads:[~2016-05-08 19:41 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-05-08 15:44 bug#23478: 25.0.93; Mouse region selection asymmetry Stephen Berman
2016-05-08 16:23 ` Eli Zaretskii
2016-05-08 18:31 ` Stephen Berman
2016-05-08 18:54 ` Eli Zaretskii
2016-05-08 19:41 ` Stephen Berman [this message]
2016-05-08 19:45 ` Eli Zaretskii
2016-07-02 23:16 ` npostavs
2016-07-03 14:33 ` Stephen Berman
2016-07-03 15:38 ` Eli Zaretskii
2016-07-03 22:24 ` Stephen Berman
2016-07-04 2:38 ` Eli Zaretskii
2016-07-04 8:45 ` Stephen Berman
2016-07-04 14:57 ` Eli Zaretskii
2016-07-04 16:56 ` Stephen Berman
2016-07-04 18:26 ` Stephen Berman
2016-07-05 17:23 ` Eli Zaretskii
2016-07-06 16:40 ` Stephen Berman
2016-07-06 18:44 ` Eli Zaretskii
2016-07-07 12:08 ` Stephen Berman
2016-07-07 15:29 ` Eli Zaretskii
2016-07-07 16:22 ` Stephen Berman
2016-07-07 16:48 ` Eli Zaretskii
2016-07-07 17:02 ` Noam Postavsky
2016-07-07 17:16 ` Eli Zaretskii
2016-07-07 18:26 ` Stephen Berman
2016-07-08 9:58 ` Stephen Berman
2016-07-08 10:14 ` Eli Zaretskii
2016-07-08 15:38 ` Stephen Berman
2016-07-07 17:04 ` Stephen Berman
2016-07-04 15:29 ` Drew Adams
2016-07-05 1:32 ` npostavs
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87shxswd5s.fsf@gmx.net \
--to=stephen.berman@gmx.net \
--cc=23478@debbugs.gnu.org \
--cc=eliz@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).