Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

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