bug#23478: 25.0.93; Mouse region selection asymmetry

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

When you select a region by double-clicking with mouse-1 and the end of
the region is below the last visible line of the window, Emacs recenters
the display, making the entire selected region visible (unless it's
larger than half the window's height).  But when you select a region by
double-clicking with mouse-1 and the beginning of the region is above
the first visible line of the window, Emacs does not recenter the
display, so the entire selected region is not visible.  To reproduce:

0. emacs -Q
1. C-h t M-g M-g 42 RET (to open the English Emacs Tutorial and put
   point on line 42).
2. C-l C-l C-l (to make line 42 the last visible line in the window).
3. Double click with mouse-1 on the `(' before "hold" in line 42.
=> The display is recentered and the region between `(' on line 42 and
   `)' on line 43 is selected and highlighted.
4. C-a C-l C-l (to clear the selection highlighting and make line 43 the
   first visible line in the window).
5. Double click with mouse-1 on the `)' after "key" in line 43.
=> Line 43 is highlighted but remains the first visible line in the
   window and the part of the region on line 42 is not visible.

This is not a program bug, since Emacs is behaving as intended, but it
is a UX asymmetry that I think it would be preferable to eliminate.  The
patch below does that, but I'm not sure it's the best way to handle
this, since I don't know whether calling `recenter' from Lisp may have
undesirable side effects that the automatic recentering Emacs redisplay
does when point moves out of the visible portion of the window does not
have.

diff --git a/lisp/mouse.el b/lisp/mouse.el
index fa355ff..c3efefe 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -531,7 +531,10 @@ 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))
+	  (recenter)))
     ;; 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))))


In GNU Emacs 25.0.93.5 (x86_64-suse-linux-gnu, GTK+ Version 3.14.15)
 of 2016-05-08 built on rosalinde
Repository revision: cd27f7396b77086b6c02eff5b2648bfba439d264
Windowing system distributor 'The X.Org Foundation', version 11.0.11601000
System Description:	openSUSE 13.2 (Harlequin) (x86_64)

Configured using:
 'configure --with-xwidgets 'CFLAGS=-Og -g3''

Configured features:
XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND DBUS GCONF GSETTINGS NOTIFY
GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS
GTK3 X11 XWIDGETS

Important settings:
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

bug#23478: 25.0.93; Mouse region selection asymmetry

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Date: Sun, 08 May 2016 17:44:49 +0200
> 
> When you select a region by double-clicking with mouse-1 and the end of
> the region is below the last visible line of the window, Emacs recenters
> the display, making the entire selected region visible (unless it's
> larger than half the window's height).  But when you select a region by
> double-clicking with mouse-1 and the beginning of the region is above
> the first visible line of the window, Emacs does not recenter the
> display, so the entire selected region is not visible.

Isn't this because Emacs always makes sure point is visible, but
there's no such requirement about the mark?  If I type "C-x C-x" after
item 5 in your recipe, the entire region becomes visible, as expected.

> This is not a program bug, since Emacs is behaving as intended, but it
> is a UX asymmetry that I think it would be preferable to eliminate.  The
> patch below does that, but I'm not sure it's the best way to handle
> this, since I don't know whether calling `recenter' from Lisp may have
> undesirable side effects that the automatic recentering Emacs redisplay
> does when point moves out of the visible portion of the window does not
> have.

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.

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

Thanks.

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

On Sun, 08 May 2016 19:23:17 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Date: Sun, 08 May 2016 17:44:49 +0200
>> 
>> When you select a region by double-clicking with mouse-1 and the end of
>> the region is below the last visible line of the window, Emacs recenters
>> the display, making the entire selected region visible (unless it's
>> larger than half the window's height).  But when you select a region by
>> double-clicking with mouse-1 and the beginning of the region is above
>> the first visible line of the window, Emacs does not recenter the
>> display, so the entire selected region is not visible.
>
> Isn't this because Emacs always makes sure point is visible, but
> there's no such requirement about the mark?  

I'm sure it is.

>                                              If I type "C-x C-x" after
> item 5 in your recipe, the entire region becomes visible, as expected.

Yes, and you also see the whole region when you type `S-C-M-b' on `)' in
step 5 instead of double clicking on it, because backward-sexp changes
point, but double-clicking does not (or rather, it puts point one
position after region-end).

>> This is not a program bug, since Emacs is behaving as intended, but it
>> is a UX asymmetry that I think it would be preferable to eliminate.  The
>> patch below does that, but I'm not sure it's the best way to handle
>> this, since I don't know whether calling `recenter' from Lisp may have
>> undesirable side effects that the automatic recentering Emacs redisplay
>> does when point moves out of the visible portion of the window does not
>> have.
>
> 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.

Steve Berman

bug#23478: 25.0.93; Mouse region selection asymmetry

[Eli Zaretskii]

> 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?

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

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

bug#23478: 25.0.93; Mouse region selection asymmetry

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: 23478@debbugs.gnu.org
> Date: Sun, 08 May 2016 21:41:19 +0200
> 
> > 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!

Glad it did the trick.

> Do you really think this should be conditioned by a user option?

I do, but let's hear from others.  Anyone?

bug#23478: 25.0.93; Mouse region selection asymmetry

[npostavs]

severity 23478 minor
tags 23478 patch
quit

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Do you really think this should be conditioned by a user option?
>
> I do, but let's hear from others.  Anyone?

This behaviour seems much preferable to me, since otherwise it's not
clear which text gets selected.  I'm not in favour of adding an option,
but if there must be one, at least let this new behaviour be the
default.

Regarding the code, I notice that using (sit-for 0) works as well.  A
comment to explain what the calls are for would be nice.

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

On Sat, 02 Jul 2016 19:16:56 -0400 npostavs@users.sourceforge.net wrote:

> severity 23478 minor
> tags 23478 patch
> quit
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Stephen Berman <stephen.berman@gmx.net>
>>> Do you really think this should be conditioned by a user option?
>>
>> I do, but let's hear from others.  Anyone?
>
> This behaviour seems much preferable to me, since otherwise it's not
> clear which text gets selected.  I'm not in favour of adding an option,
> but if there must be one, at least let this new behaviour be the
> default.

I agree on both points (prefer no option, but if so default to new).

> Regarding the code, I notice that using (sit-for 0) works as well.

Thanks.  Indeed, even a negative number works.  But zero does seem the
least arbitrary.

> A comment to explain what the calls are for would be nice.

I'll do that when the final version is settled on.  Eli, John, what's
the decision on making this behavior customizable (and if yes, what
default)?

Steve Berman

bug#23478: 25.0.93; Mouse region selection asymmetry

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  23478@debbugs.gnu.org
> Date: Sun, 03 Jul 2016 16:33:55 +0200
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >>> From: Stephen Berman <stephen.berman@gmx.net>
> >>> Do you really think this should be conditioned by a user option?
> >>
> >> I do, but let's hear from others.  Anyone?
> >
> > This behaviour seems much preferable to me, since otherwise it's not
> > clear which text gets selected.  I'm not in favour of adding an option,
> > but if there must be one, at least let this new behaviour be the
> > default.
> 
> I agree on both points (prefer no option, but if so default to new).
> 
> > Regarding the code, I notice that using (sit-for 0) works as well.
> 
> Thanks.  Indeed, even a negative number works.  But zero does seem the
> least arbitrary.
> 
> > A comment to explain what the calls are for would be nice.
> 
> I'll do that when the final version is settled on.  Eli, John, what's
> the decision on making this behavior customizable (and if yes, what
> default)?

I think backward-incompatible behavior should almost always be opt-in,
unless we have no choice.

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

On Sun, 03 Jul 2016 18:38:39 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  23478@debbugs.gnu.org
>> Date: Sun, 03 Jul 2016 16:33:55 +0200
>> 
>> > Eli Zaretskii <eliz@gnu.org> writes:
>> >
>> >>> From: Stephen Berman <stephen.berman@gmx.net>
>> >>> Do you really think this should be conditioned by a user option?
>> >>
>> >> I do, but let's hear from others.  Anyone?
>> >
>> > This behaviour seems much preferable to me, since otherwise it's not
>> > clear which text gets selected.  I'm not in favour of adding an option,
>> > but if there must be one, at least let this new behaviour be the
>> > default.
>> 
>> I agree on both points (prefer no option, but if so default to new).
>> 
>> > Regarding the code, I notice that using (sit-for 0) works as well.
>> 
>> Thanks.  Indeed, even a negative number works.  But zero does seem the
>> least arbitrary.
>> 
>> > A comment to explain what the calls are for would be nice.
>> 
>> I'll do that when the final version is settled on.  Eli, John, what's
>> the decision on making this behavior customizable (and if yes, what
>> default)?
>
> I think backward-incompatible behavior should almost always be opt-in,
> unless we have no choice.

Opting in does, however, have the problem of discoverability (a NEWS
entry notwithstanding).  I think opting in is best in cases where it's
likely that some people may prefer (or some code may depend on) the
existing behavior, or where the new behavior may bring a disadvantage in
some case.  But I don't think any of that is likely in this case
(indeed, I really think the existing behavior is a misfeature).  Your
concern about the interaction with scroll-conservatively applied to my
initial patch, but you yourself suggested a better alternative that
allays this concern.  Given that, I ask again, and not rhetorically, do
you see a strong downside to having the new behavior be the default?

Steve Berman

bug#23478: 25.0.93; Mouse region selection asymmetry

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: npostavs@users.sourceforge.net,  23478@debbugs.gnu.org
> Date: Mon, 04 Jul 2016 00:24:51 +0200
> 
> > I think backward-incompatible behavior should almost always be opt-in,
> > unless we have no choice.
> 
> Opting in does, however, have the problem of discoverability (a NEWS
> entry notwithstanding).

Since this is age-old behavior that no one complained about until now,
we can assume most users won't need it.

> I think opting in is best in cases where it's
> likely that some people may prefer (or some code may depend on) the
> existing behavior, or where the new behavior may bring a disadvantage in
> some case.  But I don't think any of that is likely in this case
> (indeed, I really think the existing behavior is a misfeature).  Your
> concern about the interaction with scroll-conservatively applied to my
> initial patch, but you yourself suggested a better alternative that
> allays this concern.  Given that, I ask again, and not rhetorically, do
> you see a strong downside to having the new behavior be the default?

Let's make one step back and describe the exact change in behavior
with the last patch, OK?  Maybe some of us (e.g., me) don't really
understand what is the change.

Thanks.

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

On Mon, 04 Jul 2016 05:38:51 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: npostavs@users.sourceforge.net,  23478@debbugs.gnu.org
>> Date: Mon, 04 Jul 2016 00:24:51 +0200
>> 
>> > I think backward-incompatible behavior should almost always be opt-in,
>> > unless we have no choice.
>> 
>> Opting in does, however, have the problem of discoverability (a NEWS
>> entry notwithstanding).
>
> Since this is age-old behavior that no one complained about until now,
> we can assume most users won't need it.

If by "it" you mean the new behavior, then I agree nobody needs it, in
the sense that it doesn't provide any functionality you can't get
another way (e.g. by selecting a region by means of key combinations by
dragging the mouse instead of by double-clicking).  Nevertheless, I've
always been slightly annoyed when I've encountered the issue, just never
enough to try and do anything about it till now.

>> I think opting in is best in cases where it's
>> likely that some people may prefer (or some code may depend on) the
>> existing behavior, or where the new behavior may bring a disadvantage in
>> some case.  But I don't think any of that is likely in this case
>> (indeed, I really think the existing behavior is a misfeature).  Your
>> concern about the interaction with scroll-conservatively applied to my
>> initial patch, but you yourself suggested a better alternative that
>> allays this concern.  Given that, I ask again, and not rhetorically, do
>> you see a strong downside to having the new behavior be the default?
>
> Let's make one step back and describe the exact change in behavior
> with the last patch, OK?  Maybe some of us (e.g., me) don't really
> understand what is the change.

It simply makes selecting a region by double-clicking with the mouse
more uniform; as I wrote in my OP, the current behavior is this:

   When you select a region by double-clicking with mouse-1 and the end
   of the region is below the last visible line of the window, Emacs
   recenters the display, making the entire selected region visible
   (unless it's larger than half the window's height).  But when you
   select a region by double-clicking with mouse-1 and the beginning of
   the region is above the first visible line of the window, Emacs does
   not recenter the display, so the entire selected region is not
   visible.

With the patch the behavior is now simply this:

   When you select a region by double-clicking with mouse-1, Emacs
   recenters the display, making the entire selected region visible
   (unless it's larger than half the window's height).

To me (and I think Noam agrees), this is the behavior I would expect,
while the current behavior is less user-friendly; I can't think of a
reason why anyone would dislike the new behavior or prefer the current
behavior, but maybe someone can provide a use case.

Steve Berman

bug#23478: 25.0.93; Mouse region selection asymmetry

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: npostavs@users.sourceforge.net,  23478@debbugs.gnu.org
> Date: Mon, 04 Jul 2016 10:45:43 +0200
> 
> > Let's make one step back and describe the exact change in behavior
> > with the last patch, OK?  Maybe some of us (e.g., me) don't really
> > understand what is the change.
> 
> It simply makes selecting a region by double-clicking with the mouse
> more uniform; as I wrote in my OP, the current behavior is this:
> 
>    When you select a region by double-clicking with mouse-1 and the end
>    of the region is below the last visible line of the window, Emacs
>    recenters the display, making the entire selected region visible
>    (unless it's larger than half the window's height).  But when you
>    select a region by double-clicking with mouse-1 and the beginning of
>    the region is above the first visible line of the window, Emacs does
>    not recenter the display, so the entire selected region is not
>    visible.
> 
> With the patch the behavior is now simply this:
> 
>    When you select a region by double-clicking with mouse-1, Emacs
>    recenters the display, making the entire selected region visible
>    (unless it's larger than half the window's height).
> 
> To me (and I think Noam agrees), this is the behavior I would expect,
> while the current behavior is less user-friendly; I can't think of a
> reason why anyone would dislike the new behavior or prefer the current
> behavior, but maybe someone can provide a use case.

Thanks, I wanted to be sure I understand the change correctly.

This is indeed a change in behavior: the display recentering in the
second situation might be undesirable, since some text that was
previously visible might become invisible.  And what will happen if
the region is larger than the window can show?

In the first situation, the mouse click actually moves point, so the
scrolling that may follow is expected.  Not so in the second case.

So I still think we should default to the old behavior.

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

On Mon, 04 Jul 2016 17:57:18 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: npostavs@users.sourceforge.net,  23478@debbugs.gnu.org
>> Date: Mon, 04 Jul 2016 10:45:43 +0200
>> 
>> > Let's make one step back and describe the exact change in behavior
>> > with the last patch, OK?  Maybe some of us (e.g., me) don't really
>> > understand what is the change.
>> 
>> It simply makes selecting a region by double-clicking with the mouse
>> more uniform; as I wrote in my OP, the current behavior is this:
>> 
>>    When you select a region by double-clicking with mouse-1 and the end
>>    of the region is below the last visible line of the window, Emacs
>>    recenters the display, making the entire selected region visible
>>    (unless it's larger than half the window's height).  But when you
>>    select a region by double-clicking with mouse-1 and the beginning of
>>    the region is above the first visible line of the window, Emacs does
>>    not recenter the display, so the entire selected region is not
>>    visible.
>> 
>> With the patch the behavior is now simply this:
>> 
>>    When you select a region by double-clicking with mouse-1, Emacs
>>    recenters the display, making the entire selected region visible
>>    (unless it's larger than half the window's height).
>> 
>> To me (and I think Noam agrees), this is the behavior I would expect,
>> while the current behavior is less user-friendly; I can't think of a
>> reason why anyone would dislike the new behavior or prefer the current
>> behavior, but maybe someone can provide a use case.
>
> Thanks, I wanted to be sure I understand the change correctly.
>
> This is indeed a change in behavior: the display recentering in the
> second situation might be undesirable, since some text that was
> previously visible might become invisible.  

But (more of) the text that is selected by mouse-click becomes visible;
surely that's more desirable, don't you think?  And again, that makes
the second situation more like in the first situation, which also seems
desirable.

>                                             And what will happen if
> the region is larger than the window can show?

Part of the region simply won't be displayed in the window, which is
nothing new: the same thing that currently happens in the first
situation.

> In the first situation, the mouse click actually moves point, so the
> scrolling that may follow is expected.  Not so in the second case.

Actually, it's easy to get this in the second situation: just call
exchange-point-and-mark once:

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 8d72753..39adc42 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -548,7 +548,11 @@ 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)))
     ;; 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))))

This makes the bevavior even more like the first situation (i.e., the
mirror image of it).  So I like this solution even better.  What do you
think?

> So I still think we should default to the old behavior.

Even with the above adjustment?  Although three of the four opinions
that have been voiced in this thread have been in favor of just having
the new behavior (though that was prior to the above adjustment), I will
defer to your decision, or if you wish, ask John to settle it.  And to
be clear, whatever the decision on a user option and concomitant default,
I would rather install the above patch, where point moves, than the
version where point does not move.

Steve Berman

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

On Mon, 04 Jul 2016 18:56:03 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> diff --git a/lisp/mouse.el b/lisp/mouse.el
> index 8d72753..39adc42 100644
> --- a/lisp/mouse.el
> +++ b/lisp/mouse.el
> @@ -548,7 +548,11 @@ 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)))
>      ;; 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))))
>
> This makes the bevavior even more like the first situation (i.e., the
> mirror image of it).  So I like this solution even better.  What do you
> think?

That patch only mirrors the first situation when the region begins above
the window; the following always changes point when clicking at what
will be the end point of the region, so this fully mirrors the first
situation, and would be the most symmetrical behavior (unless I'm
overlooking something):

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 8d72753..608a52f 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -548,7 +548,11 @@ 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 (> (posn-point (event-start event)) (region-beginning))
+	  (exchange-point-and-mark)
+	  (sit-for 0)))
     ;; 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))))

Steve Berman

bug#23478: 25.0.93; Mouse region selection asymmetry

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: npostavs@users.sourceforge.net,  23478@debbugs.gnu.org
> Date: Mon, 04 Jul 2016 18:56:03 +0200
> 
> > So I still think we should default to the old behavior.
> 
> Even with the above adjustment?

Yes.  For me, the important part is that the age-old behavior will
change.  We have no idea how many users will like it and how many
won't.  In particular, the new behavior that moves point where it
previously didn't might annoy people who intend to type after the
click.  Thus, my preference is to make this an opt-in change.  Perhaps
with time, if we hear many users asking this to be the default, we
will reverse the default value.

Thanks.

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

On Tue, 05 Jul 2016 20:23:23 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: npostavs@users.sourceforge.net,  23478@debbugs.gnu.org
>> Date: Mon, 04 Jul 2016 18:56:03 +0200
>> 
>> > So I still think we should default to the old behavior.
>> 
>> Even with the above adjustment?
>
> Yes.  For me, the important part is that the age-old behavior will
> change.  We have no idea how many users will like it and how many
> won't.  In particular, the new behavior that moves point where it
> previously didn't might annoy people who intend to type after the
> click.  Thus, my preference is to make this an opt-in change.  Perhaps
> with time, if we hear many users asking this to be the default, we
> will reverse the default value.

I want to be clear about exactly what the new behavior should be.  Since
the patch referred to by "the above adjustment" was faulty and I
followed it with an improvement, I assume "the new behavior that moves
point" refers to the latter patch.  So the user option would specify the
behavior when selecting a region which extends backward from point,
providing a choice between (i) the current behavior (as default), which
leaves point at the position of the click and does not scroll backward
if the region extends above window-start; and (ii) the new behavior,
which moves point to region-beginning, scrolling if the region extends
above window-start (the new behavior is thus the mirror image of the
current behavior when selecting a region which extends forward from
point).  Here is a patch implementing this:

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 8d72753..2f9ff6b 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -540,15 +540,31 @@ mouse-drag-vertical-line
   (interactive "e")
   (mouse-drag-line start-event 'vertical))
 \f
+(defcustom mouse-select-region-backward nil
+  "Effect of selecting a region extending backward from double click.
+
+Nil means keep point at the position clicked (region end) and
+don't scroll backward when the region extends above the top of
+the window; non-nil means move point to region beginning,
+scrolling when the region extends above the top of the window."
+  :version "26.1"
+  :type '(choice (const :tag "Keep point and don't scroll backward" nil)
+		 (const :tag "Move point and scroll if needed" t)))
+
 (defun mouse-set-point (event &optional promote-to-region)
   "Move point to the position clicked on with the mouse.
 This should be bound to a mouse click event type.
-If PROMOTE-TO-REGION is non-nil and event is a multiple-click,
-select the corresponding element around point."
+If PROMOTE-TO-REGION is non-nil and event is a multiple-click, select
+the corresponding element around point, with the resulting position of
+point determined by `mouse-select-region-backward'."
   (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 mouse-select-region-backward
+          (when (> (posn-point (event-start event)) (region-beginning))
+            (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))))


But note that, prior to the patch in my previous post, what was under
discussion as the new behavior was different: namely, scrolling if the
region extends above window-start but leaving point at the position of
the click.  This is a sort of compromise between the current behavior
and that in (ii), and it could be a third choice for the user option.
Here is a patch for this alternative:

diff --git a/lisp/mouse.el b/lisp/mouse.el
index 8d72753..19b4804 100644
--- a/lisp/mouse.el
+++ b/lisp/mouse.el
@@ -540,15 +540,37 @@ mouse-drag-vertical-line
   (interactive "e")
   (mouse-drag-line start-event 'vertical))
 \f
+(defcustom mouse-select-region-backward nil
+  "Effect of selecting a region extending backward from double click.
+
+Nil means keep point at the position clicked (region end) and
+don't scroll backward when the region extends above the top of
+the window; `keep' means keep point at region end but scroll when
+the region extends above the top of the window; `move' means move
+point to region beginning, scrolling when the region extends
+above the top of the window."
+  :version "26.1"
+  :type '(choice (const :tag "Keep point and don't scroll backward" nil)
+                 (const :tag "Keep point and scroll if needed" keep)
+		 (const :tag "Move point and scroll if needed" move)))
+
 (defun mouse-set-point (event &optional promote-to-region)
   "Move point to the position clicked on with the mouse.
 This should be bound to a mouse click event type.
-If PROMOTE-TO-REGION is non-nil and event is a multiple-click,
-select the corresponding element around point."
+If PROMOTE-TO-REGION is non-nil and event is a multiple-click, select
+the corresponding element around point, with the resulting position of
+point determined by `mouse-select-region-backward'."
   (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 mouse-select-region-backward
+          (when (> (posn-point (event-start event)) (region-beginning))
+            (exchange-point-and-mark)))
+        (when (eq mouse-select-region-backward 'keep)
+          (sit-for 0)
+          (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))))

A problem with the `keep' choice is that, when the region is too big for
the window, there is a somewhat jarring flicker due to exchanging point
and mark twice and redisplayin in between, and perhaps even worse, when
scroll-conservatively is 0, the region shown in the window can be
smaller than the text shown before selecting, due to recentering.  But
for smaller regions, the `keep' choice could be a useful option.

Do you have a preference between these two alternatives?  (Perhaps Noam
and Drew wish to chime in here, since they in effect commented only on
the `keep' choice, not the `move' choice.)

Steve Berman

bug#23478: 25.0.93; Mouse region selection asymmetry

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: npostavs@users.sourceforge.net,  23478@debbugs.gnu.org
> Date: Wed, 06 Jul 2016 18:40:53 +0200
> 
> I want to be clear about exactly what the new behavior should be.  Since
> the patch referred to by "the above adjustment" was faulty and I
> followed it with an improvement, I assume "the new behavior that moves
> point" refers to the latter patch.

Yes.

> So the user option would specify the behavior when selecting a
> region which extends backward from point, providing a choice between
> (i) the current behavior (as default), which leaves point at the
> position of the click and does not scroll backward if the region
> extends above window-start; and (ii) the new behavior, which moves
> point to region-beginning, scrolling if the region extends above
> window-start (the new behavior is thus the mirror image of the
> current behavior when selecting a region which extends forward from
> point).

Yes, that's what I had in mind.

> Here is a patch implementing this:
> 
> diff --git a/lisp/mouse.el b/lisp/mouse.el
> index 8d72753..2f9ff6b 100644
> --- a/lisp/mouse.el
> +++ b/lisp/mouse.el
> @@ -540,15 +540,31 @@ mouse-drag-vertical-line
>    (interactive "e")
>    (mouse-drag-line start-event 'vertical))
>  \f
> +(defcustom mouse-select-region-backward nil

I'd name it mouse-select-region-scroll-backward.

> But note that, prior to the patch in my previous post, what was under
> discussion as the new behavior was different: namely, scrolling if the
> region extends above window-start but leaving point at the position of
> the click.  This is a sort of compromise between the current behavior
> and that in (ii), and it could be a third choice for the user option.

I have no opinion about this.  Please do what you feel is better.

This will also need a NEWS entry, and also please see if the
description of mouse-set-point in the Emacs manual needs an update.

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

On Wed, 06 Jul 2016 21:44:44 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>
>> So the user option would specify the behavior when selecting a
>> region which extends backward from point, providing a choice between
>> (i) the current behavior (as default), which leaves point at the
>> position of the click and does not scroll backward if the region
>> extends above window-start; and (ii) the new behavior, which moves
>> point to region-beginning, scrolling if the region extends above
>> window-start (the new behavior is thus the mirror image of the
>> current behavior when selecting a region which extends forward from
>> point).
>
> Yes, that's what I had in mind.
>
>> Here is a patch implementing this:
>> 
>> diff --git a/lisp/mouse.el b/lisp/mouse.el
>> index 8d72753..2f9ff6b 100644
>> --- a/lisp/mouse.el
>> +++ b/lisp/mouse.el
>> @@ -540,15 +540,31 @@ mouse-drag-vertical-line
>>    (interactive "e")
>>    (mouse-drag-line start-event 'vertical))
>>  \f
>> +(defcustom mouse-select-region-backward nil
>
> I'd name it mouse-select-region-scroll-backward.

Using "scroll" in the name suggests that the main purpose of this
variable is to control scrolling backward, but it only controls the
final position of point, and scrolling is a by-product of that which
only happens if necessary.  Given that, do you still prefer to have
"scroll" in the name?

>> But note that, prior to the patch in my previous post, what was under
>> discussion as the new behavior was different: namely, scrolling if the
>> region extends above window-start but leaving point at the position of
>> the click.  This is a sort of compromise between the current behavior
>> and that in (ii), and it could be a third choice for the user option.
>
> I have no opinion about this.  Please do what you feel is better.

If nobody objects I'll go with the binary rather than the ternary
option, because of the display issues with the latter that I noted, and
the former is also simpler both in implementation and conceptually.

> This will also need a NEWS entry, and also please see if the
> description of mouse-set-point in the Emacs manual needs an update.

In that node ("Mouse Commands") there is no mention of the current
behavior of double clicking mouse-1, but there is a partial description
in the node "Word and Line Mouse".  There is also a cross-reference in
"Mouse Commands" to "Word and Line Mouse" in connection with mouse-3.  I
think a cross-reference in connection with mouse-1 is also appropriate,
and a description of the new user option should go in the latter node.
What do you think of the following?


diff --git a/doc/emacs/frames.texi b/doc/emacs/frames.texi
index 7e60062..231989f 100644
--- a/doc/emacs/frames.texi
+++ b/doc/emacs/frames.texi
@@ -97,7 +97,8 @@ Mouse Commands
 invoked by clicking with the left mouse button, @kbd{mouse-1}, in the
 text area of a window.  This moves point to the position where you
 clicked.  If that window was not the selected window, it becomes the
-selected window.
+selected window.  You can also activate a region by double-clicking
+mouse-1 (@pxref{Word and Line Mouse}).
 
 @vindex x-mouse-click-focus-ignore-position
   Normally, if the frame you clicked in was not the selected frame, it
@@ -215,7 +216,7 @@ Word and Line Mouse
 
 @table @kbd
 @item Double-mouse-1
-Select the text around the word which you click on.
+Select the text around the word or character which you click on.
 
 Double-clicking on a character with symbol syntax (such as
 underscore, in C mode) selects the symbol surrounding that character.
@@ -226,6 +227,17 @@ Word and Line Mouse
 constant (Emacs uses heuristics to figure out whether that character
 is the beginning or the end of it).
 
+Double-clicking on the beginning of a parenthetical grouping or
+beginning string-delimiter moves point to the end of the region,
+scrolling the buffer display forward if necessary to show the new
+location of point.  Double-clicking on the end of a parenthetical
+grouping or string-delimiter keeps point at the end of the region by
+default, so the beginning of the region will not be visible if it is
+above the top of the window; setting the user option
+@code{mouse-select-region-scroll-backward} to non-nil changes this to
+make point move to the beginning of the region, scrolling the display
+backward if necessary.
+
 @item Double-Drag-mouse-1
 Select the text you drag across, in the form of whole words.
 

One somewhat embarassing aspect of describing this option is that is
makes the default asymmetrical behavior painfully obvious without
providing a rationale for it (and I don't know of any).  I suppose we
could add "for historical reasons" after "by default"....

Steve Berman

bug#23478: 25.0.93; Mouse region selection asymmetry

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: npostavs@users.sourceforge.net,  23478@debbugs.gnu.org
> Date: Thu, 07 Jul 2016 14:08:32 +0200
> 
> >> +(defcustom mouse-select-region-backward nil
> >
> > I'd name it mouse-select-region-scroll-backward.
> 
> Using "scroll" in the name suggests that the main purpose of this
> variable is to control scrolling backward, but it only controls the
> final position of point, and scrolling is a by-product of that which
> only happens if necessary.  Given that, do you still prefer to have
> "scroll" in the name?

I'm not great at naming symbols, so I don't insist.  However, the
original name seemed slightly misleading: it could be interpreted as
if the selection will be made backward, which is incorrect.  And since
I know that the "select-region" belongs to "mouse", I'm left wondering
what is "backward" about.

Do you see my problem with the name?  If so, perhaps you can suggest a
better one.

> One somewhat embarassing aspect of describing this option is that is
> makes the default asymmetrical behavior painfully obvious without
> providing a rationale for it (and I don't know of any).  I suppose we
> could add "for historical reasons" after "by default"....

I don't think it's needed: since point doesn't move, no scrolling
should be expected.

Thanks.

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

On Thu, 07 Jul 2016 18:29:54 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: npostavs@users.sourceforge.net,  23478@debbugs.gnu.org
>> Date: Thu, 07 Jul 2016 14:08:32 +0200
>> 
>> >> +(defcustom mouse-select-region-backward nil
>> >
>> > I'd name it mouse-select-region-scroll-backward.
>> 
>> Using "scroll" in the name suggests that the main purpose of this
>> variable is to control scrolling backward, but it only controls the
>> final position of point, and scrolling is a by-product of that which
>> only happens if necessary.  Given that, do you still prefer to have
>> "scroll" in the name?
>
> I'm not great at naming symbols, so I don't insist.  However, the
> original name seemed slightly misleading: it could be interpreted as
> if the selection will be made backward, which is incorrect.  And since
> I know that the "select-region" belongs to "mouse", I'm left wondering
> what is "backward" about.

What do you understand by "selection backward"?  My intention was to
indicate that this variable controls selecting the region when you
double-click at region-end; in this it is indeed selection backward from
point, though I admit that the phrasing is not elegant.

> Do you see my problem with the name?  If so, perhaps you can suggest a
> better one.

I don't yet see your problem, because I don't know how you interpreted
"selection backward".  I did struggle a bit with the name, though, and
am not thrilled with it.  But if no one comes up with a better name and
you find this one unsuitable, I can certainly live with
mouse-select-region-scroll-backward.

>> One somewhat embarassing aspect of describing this option is that is
>> makes the default asymmetrical behavior painfully obvious without
>> providing a rationale for it (and I don't know of any).  I suppose we
>> could add "for historical reasons" after "by default"....
>
> I don't think it's needed: since point doesn't move, no scrolling
> should be expected.

What's not needed: the phrase "for historical reasons", a rationale for
the asymmetrical behavior, or any description of the user option?  In
other words, are you saying the doc changes in the patch are acceptable?

Steve Berman

bug#23478: 25.0.93; Mouse region selection asymmetry

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: npostavs@users.sourceforge.net,  23478@debbugs.gnu.org
> Date: Thu, 07 Jul 2016 18:22:42 +0200
> 
> What do you understand by "selection backward"?

mouse-select-region-backward can be interpreted as "mouse selects
region backward".

> My intention was to indicate that this variable controls selecting
> the region when you double-click at region-end

But "region-end" doesn't appear in the name.

How about mouse-select-region-at-region-end ?

> >> One somewhat embarassing aspect of describing this option is that is
> >> makes the default asymmetrical behavior painfully obvious without
> >> providing a rationale for it (and I don't know of any).  I suppose we
> >> could add "for historical reasons" after "by default"....
> >
> > I don't think it's needed: since point doesn't move, no scrolling
> > should be expected.
> 
> What's not needed: the phrase "for historical reasons", a rationale for
> the asymmetrical behavior, or any description of the user option?  In
> other words, are you saying the doc changes in the patch are acceptable?

The rationale is not needed, IMO.

bug#23478: 25.0.93; Mouse region selection asymmetry

[Noam Postavsky]

On Thu, Jul 7, 2016 at 12:48 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: npostavs@users.sourceforge.net,  23478@debbugs.gnu.org
>> Date: Thu, 07 Jul 2016 18:22:42 +0200
>>
>> What do you understand by "selection backward"?
>
> mouse-select-region-backward can be interpreted as "mouse selects
> region backward".
>
>> My intention was to indicate that this variable controls selecting
>> the region when you double-click at region-end
>
> But "region-end" doesn't appear in the name.
>
> How about mouse-select-region-at-region-end ?

IMO, it would be a bit confusing if mouse-select-region-at-region-end
= t implies point gets moved to the beginning. How about
mouse-select-region-move-to-beginning. I also suggest removing mention
of scrolling from docstring, I don't think we need to re-explain how
moving point interacts with scrolling here.

(defcustom mouse-select-region-move-to-beginning nil
  "Effect of selecting a region extending backward from double click.

Nil means keep point at the position clicked (region end);
non-nil means move point to region beginning."
  :version "26.1"
  :type '(choice (const :tag "Don't move point" nil)
                 (const :tag "Move point to beginning of region" t)))

bug#23478: 25.0.93; Mouse region selection asymmetry

[Eli Zaretskii]

> From: Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Thu, 7 Jul 2016 13:02:38 -0400
> Cc: Stephen Berman <stephen.berman@gmx.net>, 23478@debbugs.gnu.org
> 
> How about mouse-select-region-move-to-beginning.

Fine with me.

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

On Thu, 07 Jul 2016 20:16:26 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>> Date: Thu, 7 Jul 2016 13:02:38 -0400
>> Cc: Stephen Berman <stephen.berman@gmx.net>, 23478@debbugs.gnu.org
>> 
>> How about mouse-select-region-move-to-beginning.
>
> Fine with me.
>

Me too.

On Thu, 7 Jul 2016 13:02:38 -0400 Noam Postavsky <npostavs@users.sourceforge.net> wrote:

> I also suggest removing mention
> of scrolling from docstring, I don't think we need to re-explain how
> moving point interacts with scrolling here.
>
> (defcustom mouse-select-region-move-to-beginning nil
>   "Effect of selecting a region extending backward from double click.
>
> Nil means keep point at the position clicked (region end);
> non-nil means move point to region beginning."
>   :version "26.1"
>   :type '(choice (const :tag "Don't move point" nil)
>                  (const :tag "Move point to beginning of region" t)))
>

This is also more appropriate, thanks.

I'll push the changes to master as soon as I get a chance (hopefully
tomorrow).

Steve Berman

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

On Thu, 07 Jul 2016 20:26:06 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> On Thu, 07 Jul 2016 20:16:26 +0300 Eli Zaretskii <eliz@gnu.org> wrote:
>
>>> From: Noam Postavsky <npostavs@users.sourceforge.net>
>>> Date: Thu, 7 Jul 2016 13:02:38 -0400
>>> Cc: Stephen Berman <stephen.berman@gmx.net>, 23478@debbugs.gnu.org
>>> 
>>> How about mouse-select-region-move-to-beginning.
>>
>> Fine with me.
>>
>
> Me too.
>
> On Thu, 7 Jul 2016 13:02:38 -0400 Noam Postavsky
> <npostavs@users.sourceforge.net> wrote:
>
>> I also suggest removing mention
>> of scrolling from docstring, I don't think we need to re-explain how
>> moving point interacts with scrolling here.
>>
>> (defcustom mouse-select-region-move-to-beginning nil
>>   "Effect of selecting a region extending backward from double click.
>>
>> Nil means keep point at the position clicked (region end);
>> non-nil means move point to region beginning."
>>   :version "26.1"
>>   :type '(choice (const :tag "Don't move point" nil)
>>                  (const :tag "Move point to beginning of region" t)))
>>
>
> This is also more appropriate, thanks.
>
> I'll push the changes to master as soon as I get a chance (hopefully
> tomorrow).

First, two questions, to hopefully avoid further changes after pushing:

i. Currently no defcustom in master has `:version "26.1"' but several
have `:version "25.2"', so should the latter be used here too?

ii. Is the following NEWS entry ok, both in content and location?

diff --git a/etc/NEWS b/etc/NEWS
index b3a044d..286933f 100644
--- a/etc/NEWS
+++ b/etc/NEWS
@@ -56,6 +56,13 @@ affected by this, as SGI stopped supporting IRIX in December 2013.
 \f
 * Changes in Emacs 25.2
 
++++
+** The new user option 'mouse-select-region-move-to-beginning'
+controls the position of point when double-clicking mouse-1 on the end
+of a parenthetical grouping or string-delimiter: the default value nil
+keeps point at the end of the region, setting it to non-nil moves
+point to the beginning of the region.
+
 ---
 ** 'find-library-name' will now fall back on looking at 'load-history'
 to try to locate libraries that have been loaded with an explicit path

Steve Berman

bug#23478: 25.0.93; Mouse region selection asymmetry

[Eli Zaretskii]

> From: Stephen Berman <stephen.berman@gmx.net>
> Cc: Eli Zaretskii <eliz@gnu.org>,  23478@debbugs.gnu.org
> Date: Fri, 08 Jul 2016 11:58:05 +0200
> 
> i. Currently no defcustom in master has `:version "26.1"' but several
> have `:version "25.2"', so should the latter be used here too?

Yes, please.  I think we will produce 25.2 from master (after
branching it or some other Git op).

> ii. Is the following NEWS entry ok, both in content and location?

Yes, it's okay.  Don't worry about the current location, entries get
relocated before a release anyway.

Thanks.

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

On Thu, 07 Jul 2016 20:26:06 +0200 Stephen Berman <stephen.berman@gmx.net> wrote:

> I'll push the changes to master as soon as I get a chance (hopefully
> tomorrow).

Done as commit d0c0b71 and closing this bug.

Steve Berman

bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman]

On Thu, 07 Jul 2016 19:48:12 +0300 Eli Zaretskii <eliz@gnu.org> wrote:

>> From: Stephen Berman <stephen.berman@gmx.net>
>> Cc: npostavs@users.sourceforge.net,  23478@debbugs.gnu.org
>> Date: Thu, 07 Jul 2016 18:22:42 +0200
>> 
>> What do you understand by "selection backward"?
>
> mouse-select-region-backward can be interpreted as "mouse selects
> region backward".

I still don't get it, but I'll drop it.

>> My intention was to indicate that this variable controls selecting
>> the region when you double-click at region-end
>
> But "region-end" doesn't appear in the name.
>
> How about mouse-select-region-at-region-end ?

This sounds a bit convoluted and also not so clear to me; how about
referring to the action instead of the result:
mouse-double-click-at-region-end ?

>> >> One somewhat embarassing aspect of describing this option is that is
>> >> makes the default asymmetrical behavior painfully obvious without
>> >> providing a rationale for it (and I don't know of any).  I suppose we
>> >> could add "for historical reasons" after "by default"....
>> >
>> > I don't think it's needed: since point doesn't move, no scrolling
>> > should be expected.
>> 
>> What's not needed: the phrase "for historical reasons", a rationale for
>> the asymmetrical behavior, or any description of the user option?  In
>> other words, are you saying the doc changes in the patch are acceptable?
>
> The rationale is not needed, IMO.

Ok.

Steve Berman

bug#23478: 25.0.93; Mouse region selection asymmetry

[Drew Adams]

> If by "it" you mean the new behavior, then I agree nobody needs it, in
> the sense that it doesn't provide any functionality you can't get
> another way (e.g. by selecting a region by means of key combinations by
> dragging the mouse instead of by double-clicking).  Nevertheless, I've
> always been slightly annoyed when I've encountered the issue, just never
> enough to try and do anything about it till now.
> 
> >> I think opting in is best in cases where it's
> >> likely that some people may prefer (or some code may depend on) the
> >> existing behavior, or where the new behavior may bring a disadvantage in
> >> some case.  But I don't think any of that is likely in this case
> >> (indeed, I really think the existing behavior is a misfeature).  Your
> >> concern about the interaction with scroll-conservatively applied to my
> >> initial patch, but you yourself suggested a better alternative that
> >> allays this concern.  Given that, I ask again, and not rhetorically, do
> >> you see a strong downside to having the new behavior be the default?
> >
> > Let's make one step back and describe the exact change in behavior
> > with the last patch, OK?  Maybe some of us (e.g., me) don't really
> > understand what is the change.
> 
> It simply makes selecting a region by double-clicking with the mouse
> more uniform; as I wrote in my OP, the current behavior is this:
> 
>    When you select a region by double-clicking with mouse-1 and the end
>    of the region is below the last visible line of the window, Emacs
>    recenters the display, making the entire selected region visible
>    (unless it's larger than half the window's height).  But when you
>    select a region by double-clicking with mouse-1 and the beginning of
>    the region is above the first visible line of the window, Emacs does
>    not recenter the display, so the entire selected region is not
>    visible.
> 
> With the patch the behavior is now simply this:
> 
>    When you select a region by double-clicking with mouse-1, Emacs
>    recenters the display, making the entire selected region visible
>    (unless it's larger than half the window's height).
> 
> To me (and I think Noam agrees), this is the behavior I would expect,
> while the current behavior is less user-friendly; I can't think of a
> reason why anyone would dislike the new behavior or prefer the current
> behavior, but maybe someone can provide a use case.

I haven't really been following this thread.  Now that I've read
the summary description of the problem (I have not tried the fix),
here are my two cents, FWIW.

1. I agree with Eli about new features generally being opt-in, not
   opt-out.  Actually, he spoke of "backward-incompatible behavior",
   and I agree with that "almost always" approach too:

   "I think backward-incompatible behavior should almost always be
    opt-in, unless we have no choice."

2. I see plenty of _bug fixes_ that have backward-incompatible
   behavior, and that are neither opt-in nor "have no choice".
   No, I'm not going to look for a list of them.  But this is
   definitely my recollection and impression.  (And it is usually
   not a problem - I am not complaining that it is here.)

3. In this particular case, I agree with Stephen.  I really don't
   see why someone would complain about this fix.  And if someone
   does then it should be easy enough to discuss and DTRT at that
   point.

4. Also in this case, as Eli said, this is not a big deal either
   way.  But I see (so far) no reason for keeping both behaviors
   and providing a user choice here.  If the non-recentering
   behavior were the case for both directions then I can imagine
   that someone might argue for a choice (recenter or not).  But
   I don't think that will happen here.

In sum, FWIW my vote would be to fix this unconditionally, and
not bother with a user option for this.

(This should apply only to the case where the entire region _can_
be shown in the window, of course.  If it cannot (too big), then
there is little reason to recenter.)

bug#23478: 25.0.93; Mouse region selection asymmetry

[npostavs]

Drew Adams <drew.adams@oracle.com> writes:
>
> 2. I see plenty of _bug fixes_ that have backward-incompatible
>    behavior, and that are neither opt-in nor "have no choice".
>    No, I'm not going to look for a list of them.  But this is
>    definitely my recollection and impression.  (And it is usually
>    not a problem - I am not complaining that it is here.)

The line bug fixes and new features can be fuzzy at times.  In this
case, the current behaviour just feels like a (albeit very minor) bug to
me.  So it would be nice if users didn't have to opt-in to get non-buggy
behaviour.