GNU bug report logs - #23478
25.0.93; Mouse region selection asymmetry

Previous Next

Full log

Message #8 received at 23478 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stephen Berman <stephen.berman <at> gmx.net>
Cc: 23478 <at> debbugs.gnu.org
Subject: Re: bug#23478: 25.0.93; Mouse region selection asymmetry
Date: Sun, 08 May 2016 19:23:17 +0300

> From: Stephen Berman <stephen.berman <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.