Re: Proposal to improve the nomenclature of scrolling directions

[Eli Zaretskii]

> Date: Sat, 10 Nov 2012 15:10:57 +0100
> From: martin rudalics <address@hidden>
> CC: address@hidden, address@hidden, address@hidden, address@hidden, 
>  address@hidden, address@hidden, address@hidden, 
>  address@hidden
> 
>  >> Not necessarily.  We can always move point lazily, that is, whenever it
>  >> is requested.
>  >
>  > That requires changes to window-scrolling functions, since currently
>  > they do move point, and they do it non-lazily.  See
>  > window_scroll_pixel_based, where it calls SET_PT_BOTH etc.
> 
> I meant to move `point' lazily _after_ we're done with scrolling.

Do you mean moving the real point or its emulation?  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.

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

>  > And what does "whenever it is requested" means, anyway, in practical
>  > terms?
> 
> Whenever the current command is not a scroll command.  In
> `scroll-restore-mode' I do that in a pre-command hook.
> 
>  > 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.
> 
> 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.

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

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.

>  > You are describing the kludgey solution (IIUC), whereas I'm suggesting
>  > a non-kludgey one.
> 
> Every solution here will be kludgey.  Suppose you scroll a non-selected
> window and subsequently insert text into its buffer.  Would you insert
> it at its old `window-point' even if its `point' is somewhere else?

Why at window-point?  At point, of course.  Isn't this how things work
now?

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