bug#23478: 25.0.93; Mouse region selection asymmetry

[Stephen Berman <stephen.berman@gmx.net>]

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