Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics <rudalics@gmx.at>]

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

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

 > 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.  But
while it might be useful to emulate other editors in this regard, the
main deficiencies we should concentrate on are:

- When scrolling for-/backward, a window's point should appear where it
   was before we started scrolling.  Currently, it doesn't when using
   different faces and maybe in some other cases as well.

- Avoid the silly way the region is disfigured when it was scrolled
   off-screen.

 >> As long as scrolling proceeds, we can pretend (visually) that it's
 >> somewhere else.
 >
 > 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?

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.

martin