Subject: bug#23478: 25.0.93; Mouse region selection asymmetry

From: Stephen Berman <[email-masked]>
Date: Thu, 07 Jul 2016 14:08:32 +0200

On Wed, 06 Jul 2016 21:44:44 +0300 Eli Zaretskii <[email-masked]> wrote:

>> From: Stephen Berman <[email-masked]>
>
>> 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))
>>  
>> +(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