Re: Make scroll-{up, down} move point to {start, end} of newly visible text

[Spencer Baugh]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Spencer Baugh <sbaugh@janestreet.com>
>> Date: Wed, 16 Aug 2023 12:20:23 -0400
>> 
>> I thought about what behavior I want, exactly, and I think it's this:
>> when point is off-screen after scroll-up, we should first try to move
>> point to "window-end before we scrolled", and only if that position is
>> also off-screen should we move point to window-start.  (Currently we
>> unconditionally move point to window-start)
>> 
>> Like this:
>> 
>> (defun my-scroll-up-command (&optional arg)
>>   (interactive "^P")
>>   (move-to-window-line -1)
>>   (scroll-up-command arg))
>> 
>> (defun my-scroll-down-command (&optional arg)
>>   (interactive "^P")
>>   (move-to-window-line 0)
>>   (scroll-down-command arg))
>> 
>> except of course this implementation moves point even if it's not
>> necessary.
>> 
>> Does this seem like a reasonable feature to add to the scrolling code?
>
> I don't understand what you have in mind.  The above commands seem to
> do what you want only when ARG is 1.  Or what did I miss?

They're actually wrong when ARG is 1, because they move point without
needing to.  They mostly only work when ARG is nil.

See the prose description of what I want, the commands are close to but
not exactly right because they move point unnecessarily:

>> When point is off-screen after scroll-up, we should first try to move
>> point to "window-end before we scrolled", and only if that position is
>> also off-screen should we move point to window-start.  (Currently we
>> unconditionally move point to window-start)

> For scrolling just one window-full, setting next-screen-context-lines
> to 1 should do what you want.  For scrolling more than that, I don't
> understand how to generalize what you want.

The prose description I gave generalizes just fine, doesn't it?  The
prose description is completely invariant to how much scrolling is done.