bug#23478: 25.0.93; Mouse region selection asymmetry

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

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