bug#18590: 24.3.93; Scrolling changes/forgets selection

[Drew Adams <drew.adams@oracle.com>]

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