Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics <rudalics@gmx.at>]

 >> I meant to move `point' lazily _after_ we're done with scrolling.
 >
 > Do you mean moving the real point or its emulation?

When I start scrolling, I save the original position of `window-point'.
`window-point' and move `point' as usual.  When I now want to
interactively insert text into the buffer, I move `point' to the saved
original position before.

 > If the former, it
 > is currently done as part of window_scroll_pixel_based, and that part
 > will need to be changed if you want point to stay put disregarding the
 > scrolling commands.

`point' moves as before.  But we don't show it any more when it's moved.

 >> If the emulation is on and the command is not a scrolling command
 >> recognized by the emulation, move `point' to where it was before
 >> scrolling.  That's what I do in `scroll-restore-mode' (if wanted).
 >
 > You do that in scroll-restore-mode because the C code moves point.
 > But if C code won't move point in these situations, then there will be
 > no reason to move point back, because it will stay put.

Yes.  And the region would be handled automatically as well.

 >> Where would we have `forward-char' start moving when emulating such
 >> "other editors"?
 >
 > At the original point position, i.e. forward-char will return there
 > and cause point be displayed after the move.

My question was addressing your earlier statement:

 > Those "other editors" that allow point to stay out of the
 > window will scroll the display back to show point when some command is
 > invoked that modifies the buffer text.

So we do not only "scroll back" when we modify text but also when we use
commands like `forward-char' and probably in many more cases.

 >>  > Given that the modification
 >>  > commands don't require moving point, and C-v/M-v won't either (as this
 >>  > is the main justification for the feature we are discussing), what
 >>  > will?
 >>
 >> The modification commands can require moving point, if desired.
 >
 > Doesn't make sense, IMO: it defeats the reason for not moving point on
 > scroll in the first place.

The primary concerns of `scroll-restore-mode' are to preseve `point'
when scrolling back to where it was and to restore the region when
scrolling back to where `point' was.  Jumping back on anything but a
scroll command is just an option.  So I principally allow to move
`point' on scroll.

 > I think the only commands that should move point in this mode are
 > those which, well, move point.  That is, goto-char, C-f/C-b, mouse-1
 > click, etc.  And these should cause display to scroll so that point
 > comes into view.

How would commands calling `set-window-start' or `recenter' be
classified in this regard?

 >> A basic invariant of Emacs is that at top-level any buffer's `point'
 >> coincides with `window-point' of the selected window, provided the
 >> buffer appears there.  Violating this invariant means we have to rethink
 >> lots of code, including things as fragile as the window configuration
 >> code.
 >
 > I don't think anything I said violates this.  What am I missing?

Ok.  Then `window-start' <= `window-point' <= `window-end' is no more an
invariant?

martin