Re: Proposal to improve the nomenclature of scrolling directions

[martin rudalics]

> I'm not sure we're talking about the same thing.  I'm just talking about
> the fact that the code he has right now does something similar to
> advising/redefining some functions (which is the only way to do it for
> an external package),

Scrolling usually happens via commands.  So external packages can always
use pre- and post-command hooks (which I obviously not recommend).

> and I'd rather just change those functions in the
> source code instead.

AFAICT scrolling is partially implemented in the scroll functions and
partially in the display engine.  For me, implementing a thing like
`scroll-in-place' means to leave the scroll functions mainly untouched -
we'd just record the original window-point and window-start positions
there.  Then we need a `scroll-point' overlay for the "line is too
short" case (Kim Storm has implemented a similar feature in his
rectangle code) and adjust it in a `post-display' hook - the one you've
been asking for in the past decade.  Also, that `post-display' hook
would have to optionally handle the case where scrolling gets back to
the original point and the user wants the window-start position to match
the position it had before the scrolling sequence started.

martin