bug#18590: 24.3.93; Scrolling changes/forgets selection

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Drew Adams]

> > 4. Scroll the window with the scroll bar or the mouse.
> > The selection changes as the window is scrolled up and down.
> 
> 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.

Yes, it's well known.  But IMO not ideal behavior.

The same thing does not happen if you select with the mouse (e.g.
drag the selection past the window bottom.  And it does not happen
if you set mark and then use C-v to move past the window bottom.

The problem is not that point is kept in the window - that is
desirable.  The point is the lack of a mark at the other end, so
the selected text shrinks (that's not really a problem, since what
is no longer selected is off-screen anyway), and you cannot use
C-x C-x to get back the region you had.  That loss of the original
region is the problem.  With the other methods I just mentioned,
you can use C-x C-x to get the region back.

I see the problem only when the scroll bar is used.  Not sure
what the OP meant by "or with the mouse".  Perhaps he meant
a window-scrolling mouse.  I don't see the problem when I drag
the selection using the mouse, at least.

And if I select a bit of text and then use the mouse wheel to
scroll the window I don't see the problem either.  In that case,
the scrolling immediately deselects the text, unlike the case
when I use the scroll bar.

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Eli Zaretskii]

> Date: Tue, 30 Sep 2014 08:06:48 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: 18590@debbugs.gnu.org
> 
> The same thing does not happen if you select with the mouse (e.g.
> drag the selection past the window bottom.

Of course it does: dragging the mouse moves point.

> And it does not happen if you set mark and then use C-v to move past
> the window bottom.

Only point must be in the view; the mark might be outside of it, as
you well know.

> And if I select a bit of text and then use the mouse wheel to
> scroll the window I don't see the problem either.

You don't use Emacs, if you don't see the problem.

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Drew Adams]

> > The same thing does not happen if you select with the mouse (e.g.
> > drag the selection past the window bottom.
> 
> Of course it does: dragging the mouse moves point.

What I said is that loss of the starting position, as one end of
the region, does not occur.  You can use `C-x C-x' to select the
region between the new point (where the mouse dragged to) and the
starting position of the drag.  The fact that the window scrolled
during the drag does not affect this region.  Which is as it should be.

> > And it does not happen if you set mark and then use C-v to move
> > past the window bottom.
> 
> Only point must be in the view; the mark might be outside of it, as
> you well know.

Yes.  And both mouse dragging and C-SPC set the mark (which they
should).

> > And if I select a bit of text and then use the mouse wheel to
> > scroll the window I don't see the problem either.
> 
> You don't use Emacs, if you don't see the problem.

C-SPC C-5 C-f
Then scroll using the mouse wheel. Then C-x C-x. The region is from
point back to the mark. As it should be.

Or press mouse-1, drag it a few chars, and release mouse-1. Then
scroll using the mouse wheel. Again, C-x C-x selects from the new
point back to the mouse-drag starting position - because mouse drag
sets mark. Again, the behavior is as it should be.

Or S-right a few times, to select a few chars. Then scroll using
the mouse wheel. Again, C-x C-x selects from the new point back to
where you first used S-right (the mark). Again, the behavior is as
it should be.

All of these are what I meant by not seeing the problem with
mouse-wheel window scrolling.  What did you mean by it?
All of these behaviors are similar.

I thought, but I guess now that I was mistaken, that I saw the
following, different behavior for the scroll bar:

Select some text (using any method) and then scroll using the
vertical scroll bar.   I thought I saw that the region was kept
active (and point was of course moved to follow the window
scrolling, as it should be), but the other end of the active
region changed from its original beginning to the new window
start position. So C-x C-x lost the original region start and
was now between the new point (from scrolling) and the
window-start position.

I could have sworn that I observed that (including this morning),
but I cannot seem to repro it now.  So I guess scroll-bar
scrolling is not problematic either.  Sorry for that noise.

---

Actually, now that I think more about it, I think the seeming
gotcha is this, and it corresponds to the OP report wrt C-x h.

Because scrolling moves point, if the direction of scrolling
is toward the mark (away from point) then the original position
is lost, and you cannot recuperate it.  This is logical, but it
can seem unnatural.

E.g.: Double-click the opening or closing paren of a defun.
That puts point at the end of the selected defun.  C-x C-x to
put point at the beginning (for whatever reason).  Now scroll down.

Scrolling moves point, of course.  Visually, you can (mistakenly)
think that the region is being extended _from the original point_,
past the mark, to the scroll position (new point).

Of course this is not the case - the region is always between the
mark and (the new) point.  It can seem unnatural because (a) the
defun was selected initially, (b) scrolling visibly extends the
region, and (c) the other (mark) end of the region is no longer
on the screen, so you do not see that the region no longer
includes the initially selected defun.

I don't know whether it might make sense for scrolling to
first either deactivate the region or swap point and mark (if
it keeps the region active).

If it deactivated the region the same "problem" would be present,
but at least you would not see the region being extended and
mistakenly assume that it was being extended from the farthest
position from the scroll direction (i.e. from point).

Am I being clear?  Maybe put it this way: With some text
selected (and the region active), regardless of which end of
the region point is, the region would be kept active (as now),
but point would first be swapped with mark, whenever the
scrolling direction was toward mark (away from point).

What this would amount to is trying to compensate for possibly
forgetting to use C-x C-x to swap point and mark _before_
scrolling.

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Eli Zaretskii]

> Date: Tue, 30 Sep 2014 09:43:05 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: nljlistbox2@gmail.com, 18590@debbugs.gnu.org
> 
> > > And if I select a bit of text and then use the mouse wheel to
> > > scroll the window I don't see the problem either.
> > 
> > You don't use Emacs, if you don't see the problem.
> 
> C-SPC C-5 C-f
> Then scroll using the mouse wheel. Then C-x C-x. The region is from
> point back to the mark.

But point moves when you scroll, so the selected portion of text
changes.  The OP wanted the selection to remain unchanged on both ends
(at least that's my understanding of the report).

> Or press mouse-1, drag it a few chars, and release mouse-1. Then
> scroll using the mouse wheel. Again, C-x C-x selects from the new
> point back to the mouse-drag starting position

"From the _NEW_ point", exactly.  Ergo, the selection changed on one
end.

> All of these are what I meant by not seeing the problem with
> mouse-wheel window scrolling.

We have different notions of "the problem".

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Drew Adams]

> But point moves when you scroll, so the selected portion of text
> changes.  The OP wanted the selection to remain unchanged on both
> ends (at least that's my understanding of the report).

Did you see the behavior I suggested might be an improvement?
I think it might respond to what the OP was expecting.

There might be a downside to what I suggested - haven't thought
much about it.  But I do think it responds to the gotcha that
has bitten me and I think is biting the OP.  You have something
selected.  Scrolling gives you the (mistaken) impression that you
are only enlarging that selection.

Consider what mouse-3 does after you have selected some text as
somewhat of an analogy.  It does not matter which end of the
initially selected text point is at.  When you click mouse-3
outside the region, the region is extended to the click position.
Similarly, if you click inside the region, it is reduced to the
click position.  And the other end of the initially selected
region is not changed - regardless of whether point or mark was
at that end.

That is more or less what my suggest was for scrolling: have it
extend (or reduce, if scrolling toward point and away from mark)
the region, but have it keep the other end of the original
region.  It would have to be kept as mark, of course, since
scrolling moves the point end of the region.  That is just what
is done by mouse-3 too: it moves point to the click position
and puts mark at the far end of the region (which position does
not change).

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Eli Zaretskii]

> Date: Tue, 30 Sep 2014 10:10:42 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: nljlistbox2@gmail.com, 18590@debbugs.gnu.org
> 
> > But point moves when you scroll, so the selected portion of text
> > changes.  The OP wanted the selection to remain unchanged on both
> > ends (at least that's my understanding of the report).
> 
> Did you see the behavior I suggested might be an improvement?
> I think it might respond to what the OP was expecting.

That's for the OP to tell.

bug#18590: 24.3.93; Scrolling changes/forgets selection

[N. Jackson]

After highlighting/selecting text in a window, scrolling the window
vertically with the scroll bar or with the mouse moves the selection so
that text intentionally selected is no longer selected.

To reproduce:

1. emacs -Q

2. Open a file "longer" than the window such as the Emacs README file. E.g. C-x f R E A D M E

3. C-x h    ; Select all the text in the window.

4. Scroll the window with the scroll bar or the mouse.

Expected behaviour:

The text that is selected/highlighted remains selected/highlighted.

Observed behaviour:

The selection changes as the window is scrolled up and down.

===

Note 1: This also happens when the selected text was selected by holding
down the shift key and using the arrow keys to extend the selection, or
if the text is selected with the mouse.

Note 2: When a smaller region is selected, the selection is sometimes
lost entirely after it is scrolled off the top or bottom of the window
and then scrolled back in to view.

Note 3: I see the same (or similar) behaviour in Emacs 24.3.1 (which is
the oldest version I have on this system), but that does not make it
correct. Is this bizarre behaviour intended? It seems that if the user
makes a selection, Emacs should not change their selection without good
reason; is there a good reason?


In GNU Emacs 24.3.93.1 (x86_64-unknown-linux-gnu, GTK+ Version 3.8.8)
 of 2014-08-18 on moondust
Windowing system distributor `Fedora Project', version 11.0.11404000
System Description:	Fedora release 19 (Schrödinger’s Cat)

Configured using:
 `configure --prefix=/home/nlj/local/ 'CFLAGS=-O0 -g3 -ggdb''

Important settings:
  value of $LC_MONETARY: en_DK.utf8
  value of $LC_NUMERIC: en_DK.utf8
  value of $LC_TIME: en_DK.utf8
  value of $LANG: en_CA.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: Fundamental

Minor modes in effect:
  tooltip-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> C-g <C-home> <C-end> C-x h <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> <mouse-1> 
<mouse-1> <mouse-1> <mouse-1> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <menu-bar> <help-menu> <se
nd-emacs-bug-report>

Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
README has auto save data; consider M-x recover-this-file
Mark set [2 times]
byte-code: Beginning of buffer [2 times]
Quit
Mark set [2 times]
Quit

Load-path shadows:
None found.

Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
help-fns mail-prsvr mail-utils help-mode easymenu time-date tooltip
electric uniquify ediff-hook vc-hooks lisp-float-type mwheel x-win x-dnd
tool-bar dnd fontset image regexp-opt fringe tabulated-list newcomment
lisp-mode prog-mode register page menu-bar rfn-eshadow timer select
scroll-bar mouse jit-lock font-lock syntax facemenu font-core frame cham
georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese hebrew greek romanian slovak czech european ethiopic
indian cyrillic chinese case-table epa-hook jka-cmpr-hook help simple
abbrev minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
dbusbind gfilenotify dynamic-setting system-font-setting
font-render-setting move-toolbar gtk x-toolkit x multi-tty emacs)

Memory information:
((conses 16 75209 7674)
 (symbols 48 17706 0)
 (miscs 40 82 139)
 (strings 32 9413 4196)
 (string-bytes 1 268665)
 (vectors 16 9048)
 (vector-slots 8 386144 15091)
 (floats 8 64 369)
 (intervals 56 282 22)
 (buffers 960 13)
 (heap 1024 27655 1006))

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Date: Tue, 30 Sep 2014 10:07:02 -0300
> 
> 1. emacs -Q
> 
> 2. Open a file "longer" than the window such as the Emacs README file. E.g. C-x f R E A D M E
> 
> 3. C-x h    ; Select all the text in the window.
> 
> 4. Scroll the window with the scroll bar or the mouse.
> 
> Expected behaviour:
> 
> The text that is selected/highlighted remains selected/highlighted.
> 
> Observed behaviour:
> 
> The selection changes as the window is scrolled up and down.
> 
> ===
> 
> Note 1: This also happens when the selected text was selected by holding
> down the shift key and using the arrow keys to extend the selection, or
> if the text is selected with the mouse.
> 
> Note 2: When a smaller region is selected, the selection is sometimes
> lost entirely after it is scrolled off the top or bottom of the window
> and then scrolled back in to view.
> 
> Note 3: I see the same (or similar) behaviour in Emacs 24.3.1 (which is
> the oldest version I have on this system), but that does not make it
> correct. Is this bizarre behaviour intended? It seems that if the user
> makes a selection, Emacs should not change their selection without good
> reason; is there a good reason?

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.

bug#18590: 24.3.93; Scrolling changes/forgets selection

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

bug#18590: 24.3.93; Scrolling changes/forgets selection

[martin rudalics]

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

I addressed some of these issues here:

https://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01892.html

martin

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Stefan Monnier]

> I addressed some of these issues here:
> https://lists.gnu.org/archive/html/emacs-devel/2008-02/msg01892.html

Sounds like a good candidate for GNU ELPA.


        Stefan

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Eli Zaretskii]

> From: nljlistbox2@gmail.com (N. Jackson)
> Date: Tue, 30 Sep 2014 14:42:31 -0300
> 
> 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?

Emacs always keeps point visible, it's one of the cornerstones of its
display engine.

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

Others will disagree.

It should be possible to implement a mode where point doesn't have to
be in view, but doing so will require non-trivial changes.  Patches
welcome.

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

Try customizing scroll-preserve-screen-position.

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

You can have that today if you type "C-SPC" before scrolling.  Then
typing "C-x C-x" after scrolling will get you back where you started.

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Stefan Monnier]

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

A design decision.  As mentioned in
http://stackoverflow.com/questions/9616623/ctrl-up-down-style-scrolling-in-emacs/9807039#9807039,
the behavior you expect could be implemented, but nobody bothered to do
so yet.


        Stefan

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Alan Mackenzie]

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

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Stefan Monnier]

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

You use the special new key-binding which says "Move point to a visible
spot in the window".

Similarly, we could add a command that does "Move point back to the
position it had before we started scrolling", which would provide some
of the behavior that N. Jackson is requesting.


        Stefan

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Drew Adams]

> Similarly, we could add a command that does "Move point back to the
> position it had before we started scrolling", which would provide
> some of the behavior that N. Jackson is requesting.

As Eli said, "That's for the OP to tell."

But I don't think N. Jackson is asking that point be moved back to
the position it had before scrolling (the buffer beginning, in his
use case).

I think he is asking that the region not lose its other end, i.e.,
that it extend back to the buffer beginning, from the scrolled-to
position.  I think he is OK with point remaining at the scrolled
position, but he wants the region to extend back to bob.  Scrolling
should extend (or reduce) one end of the region, but it should not
affect the other end.

I think the right behavior is what I suggested: If the region is
active then swap point and mark before scrolling, if scrolling is
in the direction away from point and toward mark.

  Have scrolling extend (or reduce, if scrolling toward point and
  away from mark) the region, but have it keep the other end of the
  original region.  It would have to be kept as mark, of course,
  since scrolling moves the point end of the region.  That is just
  what is done by mouse-3 too...

But "That's for the OP to tell."

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Lars Ingebrigtsen]

nljlistbox2@gmail.com (N. Jackson) writes:

> After highlighting/selecting text in a window, scrolling the window
> vertically with the scroll bar or with the mouse moves the selection so
> that text intentionally selected is no longer selected.
>
> To reproduce:
>
> 1. emacs -Q
>
> 2. Open a file "longer" than the window such as the Emacs README file. E.g. C-x f R E A D M E
>
> 3. C-x h    ; Select all the text in the window.
>
> 4. Scroll the window with the scroll bar or the mouse.
>
> Expected behaviour:
>
> The text that is selected/highlighted remains selected/highlighted.
>
> Observed behaviour:
>
> The selection changes as the window is scrolled up and down.

(I'm going through old bug reports that unfortunately weren't resolved
at the time.)

This behaviour is still present in Emacs 29, and is due to Emacs always
keeping point visible in the window, and the region being the area
between point and mark.

I remember Po Lu doing some work at allowing point to be outside the
window, which would fix this issue, I think?  But I forget what the
state of that work is, so I've added Lu to the CC's; perhaps he has some
comments.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#18590: 24.3.93; Scrolling changes/forgets selection

[Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> I remember Po Lu doing some work at allowing point to be outside the
> window, which would fix this issue, I think?  But I forget what the
> state of that work is, so I've added Lu to the CC's; perhaps he has some
> comments.

I still keep that code working with regular rebasing from master, but
it's not being actively worked on at the moment.

Judging by the positive feedback from users of
pixel-scroll-precision-mode, they do not mind the minor problems with
scrolling around very tall images, which was the main motivation for
that feature, so I'm not working on it right now.