unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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))))







  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).