bug#18590: 24.3.93; Scrolling changes/forgets selection

[nljlistbox2@gmail.com (N. Jackson)]

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.

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.

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

Regards,
N. Jackson.