all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stephen Berman <stephen.berman@gmx.net>
Cc: 23478@debbugs.gnu.org
Subject: bug#23478: 25.0.93; Mouse region selection asymmetry
Date: Sun, 08 May 2016 19:23:17 +0300	[thread overview]
Message-ID: <83eg9cecy2.fsf@gnu.org> (raw)
In-Reply-To: <878tzky2oe.fsf@gmx.net> (message from Stephen Berman on Sun, 08 May 2016 17:44:49 +0200)

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





  reply	other threads:[~2016-05-08 16:23 UTC|newest]

Thread overview: 31+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-08 15:44 bug#23478: 25.0.93; Mouse region selection asymmetry Stephen Berman
2016-05-08 16:23 ` Eli Zaretskii [this message]
2016-05-08 18:31   ` Stephen Berman
2016-05-08 18:54     ` Eli Zaretskii
2016-05-08 19:41       ` Stephen Berman
2016-05-08 19:45         ` Eli Zaretskii
2016-07-02 23:16           ` npostavs
2016-07-03 14:33             ` Stephen Berman
2016-07-03 15:38               ` Eli Zaretskii
2016-07-03 22:24                 ` Stephen Berman
2016-07-04  2:38                   ` Eli Zaretskii
2016-07-04  8:45                     ` Stephen Berman
2016-07-04 14:57                       ` Eli Zaretskii
2016-07-04 16:56                         ` Stephen Berman
2016-07-04 18:26                           ` Stephen Berman
2016-07-05 17:23                           ` Eli Zaretskii
2016-07-06 16:40                             ` Stephen Berman
2016-07-06 18:44                               ` Eli Zaretskii
2016-07-07 12:08                                 ` Stephen Berman
2016-07-07 15:29                                   ` Eli Zaretskii
2016-07-07 16:22                                     ` Stephen Berman
2016-07-07 16:48                                       ` Eli Zaretskii
2016-07-07 17:02                                         ` Noam Postavsky
2016-07-07 17:16                                           ` Eli Zaretskii
2016-07-07 18:26                                           ` Stephen Berman
2016-07-08  9:58                                             ` Stephen Berman
2016-07-08 10:14                                               ` Eli Zaretskii
2016-07-08 15:38                                             ` Stephen Berman
2016-07-07 17:04                                         ` Stephen Berman
2016-07-04 15:29                       ` Drew Adams
2016-07-05  1:32                         ` npostavs

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83eg9cecy2.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=23478@debbugs.gnu.org \
    --cc=stephen.berman@gmx.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.