unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Alan Mackenzie <acm@muc.de>
To: gnu-emacs-bug@moderators.isc.org
Subject: bug#18590: 24.3.93; Scrolling changes/forgets selection
Date: Wed, 1 Oct 2014 13:29:07 +0000 (UTC)	[thread overview]
Message-ID: <m0gvj3$vql$1@colin.muc.de> (raw)
In-Reply-To: <87k34li7ex.fsf@moondust.localdomain>

N. Jackson <nljlistbox2@gmail.com> wrote:
> At 11:28 -0300 on Tuesday 2014-09-30, Eli Zaretskii wrote:

>> Yes, there's a good reason: a selection in Emacs is always between
>> point and the mark, and when scrolling causes it to go off the
>> displayed portion of the buffer, Emacs moves point to bring it back
>> into view, which changes the selected portion of the text.

> Hmm... I see. But why does point need to be visible?

> It makes sense to me for a program to scroll the window to keep point in
> view when the user moves point; but it doesn't make sense to me for a
> program to move point when the user scrolls the window.

Suppose you've scrolled the window so that point is no longer in it, and
you now want to set point to somewhere now visible; how are you going to
do it?  How are you going to indicate the place to put point?  Nearly all
commands which work at a specific position do so at point.  Your answer is
going to be "click with the mouse".  But Emacs, as a fundamental design
feature, works on mouse-less systems.

> After all, point is the locus of the user's interaction with the
> contents of the buffer; presumably if they want to move that locus
> somewhere else, the user will move point explicitly. It makes little
> sense for the program to move point in this case -- even if it happens
> to have correctly read the mind of the user and the user really was
> scrolling the window with the intention of moving point, the program has
> no way of guessing in which column and row the user was going to put it,
> so it can essentially never do the right thing.

When I scroll a window, I always want point in that window, so that I
can easily start editing things there, etc..  In the instances when I want
to go back, I set mark first before scrolling, or scroll with a command
that itself sets the mark.

> Anyway, if point must be moved, please can it be put back automatically
> where it belongs when the user scrolls the window back and point's
> correct location is once again in view? Consider this a wishlist request.

> I'd also like to have typing, or any command involving point, scroll the
> window so that the correct location of point comes into view and then act on
> point where it belongs rather than where Emacs has "randomly" moved it.

That is a "feature" I most hate with so many GUI editing programs.  I have
scrolled a buffer somewhere to look at things, and absent-mindedly start
typing, or even worse touch an arrow key, or something - then BANG!!!! my
entire mental context is explosively wiped out, scrolling the buffer back
to point and leaving me no way to go back to where I was looking at.

> Of course this would have to be an optional behaviour, something like a
> (setq point-follows-window nil). Consider it as second wishlist request?

I'm glad you said that.  ;-)

> Thanks.

> Regards,
> N. Jackson.

-- 
Alan Mackenzie (Nuremberg, Germany).






  parent reply	other threads:[~2014-10-01 13:29 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-09-30 13:07 bug#18590: 24.3.93; Scrolling changes/forgets selection N. Jackson
2014-09-30 14:28 ` Eli Zaretskii
2014-09-30 17:42   ` N. Jackson
2014-09-30 17:56     ` martin rudalics
2014-09-30 19:22       ` Stefan Monnier
2014-09-30 17:59     ` Eli Zaretskii
2014-09-30 18:09     ` Stefan Monnier
     [not found]   ` <mailman.10089.1412098998.1147.bug-gnu-emacs@gnu.org>
2014-10-01 13:29     ` Alan Mackenzie [this message]
2014-10-01 14:42       ` Stefan Monnier
2014-10-01 14:59         ` Drew Adams
2022-04-13  0:37 ` Lars Ingebrigtsen
2022-04-13  0:50   ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found] <<87k34li7ex.fsf@moondust.localdomain>
     [not found] ` <<83ppedkwrs.fsf@gnu.org>
2014-09-30 15:06   ` Drew Adams
2014-09-30 15:30     ` Eli Zaretskii
     [not found] <<69d7a976-96b7-49c6-bb96-e69f2fa8c93e@default>
     [not found] ` <<83fvf9ktwd.fsf@gnu.org>
2014-09-30 16:43   ` Drew Adams
2014-09-30 17:00     ` Eli Zaretskii
     [not found]   ` <<4a1fd296-dc2f-4fb3-a854-0b4acea62f72@default>
     [not found]     ` <<8361g5kpqb.fsf@gnu.org>
2014-09-30 17:10       ` Drew Adams
2014-09-30 17:44         ` Eli Zaretskii

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

  List information: https://www.gnu.org/software/emacs/

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

  git send-email \
    --in-reply-to='m0gvj3$vql$1@colin.muc.de' \
    --to=acm@muc.de \
    --cc=gnu-emacs-bug@moderators.isc.org \
    /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 public inbox

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

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).