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

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

[Spencer Baugh]

After I use scroll-up or scroll-down, I want to start reading the new
text on the screen.  But it's easy to lose track of where the new text
start, especially with larger values of next-screen-context-lines.

So, I would like scrolling to move point to the division between old and
new text.  Then the location of the cursor will help me keep track of
which text is new and which text is old.

Concretely, this means scroll-up should put point at the beginning of
the new text (and therefore at the end of the old text), and scroll-down
should put point at the end of the new text (and therefore at the
beginning of the old text).

Is this possible?

Alternative suggestions for how I can keep track of what text is new on
screen after scrolling are also appreciated.

I think I only want this for scroll-{up,down} and
scroll-other-window{,-down} but possibly it would make sense for other
commands which I don't know.

(I would file a bug requesting this feature, but scrolling is so
fundamental that perhaps this is already supported by some combination
of features which I don't know)

RE: [External] : Make scroll-{up, down} move point to {start, end} of newly visible text

[Drew Adams]

Not exactly what you requested, but maybe one of these
will help:

1. `hl-spotlight-mode', in `hl-spotlight.el'

https://www.emacswiki.org/emacs/download/hl-spotlight.el

2. `crosshairs-mode', in `crosshairs.el'

https://www.emacswiki.org/emacs/download/crosshairs.el

(That one requires `hl-line+.el', same URL prefix.)

There are likely lots of libraries that offer ways to
focus on what you want to focus on, e.g., to keep track
of your reading.

Even plain `hl-line-mode.el' does that, to some degree.

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

[hw]

On Tue, 2023-08-01 at 01:26 +0000, Drew Adams wrote:
> Not exactly what you requested, but maybe one of these
> will help:
> 
> 1. `hl-spotlight-mode', in `hl-spotlight.el'
> 
> https://www.emacswiki.org/emacs/download/hl-spotlight.el
> 
> 2. `crosshairs-mode', in `crosshairs.el'
> 
> https://www.emacswiki.org/emacs/download/crosshairs.el
> 
> (That one requires `hl-line+.el', same URL prefix.)
> 
> There are likely lots of libraries that offer ways to
> focus on what you want to focus on, e.g., to keep track
> of your reading.
> 
> Even plain `hl-line-mode.el' does that, to some degree.

Good idea --- isn't that part of emacs?  I have


(setq global-hl-line-mode t)
(set-face-background hl-line-face "#200020")


That goes with green text on black background and blink-cursor-mode
set to nil (because the blink is unsettling for me).  Point is red,
and that quite sticks out.

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

[Michael Heerdegen]

Spencer Baugh <sbaugh@janestreet.com> writes:

> Alternative suggestions for how I can keep track of what text is new on
> screen after scrolling are also appreciated.

This is the purpose of "on-screen.el" (Gnu Elpa).

Michael.

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

[Drew Adams]

> > Alternative suggestions for how I can keep track of what text is new on
> > screen after scrolling are also appreciated.
> 
> This is the purpose of "on-screen.el" (Gnu Elpa).

I forgot about this.  Very good.

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

[hw]

On Mon, 2023-07-31 at 16:18 -0400, Spencer Baugh wrote:
> After I use scroll-up or scroll-down, I want to start reading the new
> text on the screen.  But it's easy to lose track of where the new text
> start, especially with larger values of next-screen-context-lines.
> 
> So, I would like scrolling to move point to the division between old and
> new text.  Then the location of the cursor will help me keep track of
> which text is new and which text is old.
>
> Concretely, this means scroll-up should put point at the beginning of
> the new text (and therefore at the end of the old text), and scroll-down
> should put point at the end of the new text (and therefore at the
> beginning of the old text).
> 
> Is this possible?

Maybe try the following:


(setq scroll-preserve-screen-position t)
(setq scroll-conservatively 0)
(setq scroll-margin 1)


With this, I can see point and that is where the text scrolls to.

> Alternative suggestions for how I can keep track of what text is new on
> screen after scrolling are also appreciated.
> 
> I think I only want this for scroll-{up,down} and
> scroll-other-window{,-down} but possibly it would make sense for other
> commands which I don't know.
> 
> (I would file a bug requesting this feature, but scrolling is so
> fundamental that perhaps this is already supported by some combination
> of features which I don't know)

Have you tried scroll-lock-mode?

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

[Spencer Baugh]

hw <hw@adminart.net> writes:
> On Mon, 2023-07-31 at 16:18 -0400, Spencer Baugh wrote:
>> After I use scroll-up or scroll-down, I want to start reading the new
>> text on the screen.  But it's easy to lose track of where the new text
>> start, especially with larger values of next-screen-context-lines.
>> 
>> So, I would like scrolling to move point to the division between old and
>> new text.  Then the location of the cursor will help me keep track of
>> which text is new and which text is old.
>>
>> Concretely, this means scroll-up should put point at the beginning of
>> the new text (and therefore at the end of the old text), and scroll-down
>> should put point at the end of the new text (and therefore at the
>> beginning of the old text).
>> 
>> Is this possible?
>
> Maybe try the following:
>
>
> (setq scroll-preserve-screen-position t)
> (setq scroll-conservatively 0)
> (setq scroll-margin 1)
>
>
> With this, I can see point and that is where the text scrolls to.

No, I don't think this does what I said at all, I'm afraid.

>> Alternative suggestions for how I can keep track of what text is new on
>> screen after scrolling are also appreciated.
>> 
>> I think I only want this for scroll-{up,down} and
>> scroll-other-window{,-down} but possibly it would make sense for other
>> commands which I don't know.
>> 
>> (I would file a bug requesting this feature, but scrolling is so
>> fundamental that perhaps this is already supported by some combination
>> of features which I don't know)
>
> Have you tried scroll-lock-mode?

Yes, it's nice, but I also want the normal scroll-{up,down} commands to
work.

I think scroll-lock-mode could do with a more convenient default
binding, also.  A lot of programmers, including me, have keyboards which
don't have a scroll lock key...

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

[hw]

On Tue, 2023-08-01 at 10:45 -0400, Spencer Baugh wrote:
> hw <hw@adminart.net> writes:
> > On Mon, 2023-07-31 at 16:18 -0400, Spencer Baugh wrote:
> > > After I use scroll-up or scroll-down, I want to start reading the new
> > > text on the screen.  But it's easy to lose track of where the new text
> > > start, especially with larger values of next-screen-context-lines.
> > > 
> > > So, I would like scrolling to move point to the division between old and
> > > new text.  Then the location of the cursor will help me keep track of
> > > which text is new and which text is old.
> > > 
> > > Concretely, this means scroll-up should put point at the beginning of
> > > the new text (and therefore at the end of the old text), and scroll-down
> > > should put point at the end of the new text (and therefore at the
> > > beginning of the old text).
> > > 
> > > Is this possible?
> > 
> > Maybe try the following:
> > 
> > 
> > (setq scroll-preserve-screen-position t)
> > (setq scroll-conservatively 0)
> > (setq scroll-margin 1)
> > 
> > 
> > With this, I can see point and that is where the text scrolls to.
> 
> No, I don't think this does what I said at all, I'm afraid.

Are you actually using scroll-down and scroll-up or scroll-down-command and
scroll-up-command?

IIUC the documentation of scroll-down, when setting
‘next-screen-context-lines’ to zero, scroll-down would scroll the
contents of the buffer up such that the first line of new text would
be at the top of the window.  You could then (somehow) move point to
the top of the window, which would put it into the first line of the
new text.

Scroll-up could be done accordingly.  For either direction, it would
make sense to have the new text always start at the top of the window
because the text always needs to be within the window to be read.

And you somehow need to define where on the screen you want to start
reading the new text.  If you want to start reading at point, you may
not be able to read new text after scrolling down when point is in the
bottom line of the window because the new text would have to remain
outside the window.  Same goes for scrolling up when mark is in the
top line of the buffer.

Do you need to start reading where the mark is, or does it suffice
when the new text always starts of the top the window?

If you need to start reading at point, perhaps you can create a
function that figures out how many lines are between point and the
last/first line in the window and scrolls the text only so many lines
as to bring the first line of the new text to where point is.  I
don't know if that's possible ...

> > > Alternative suggestions for how I can keep track of what text is new on
> > > screen after scrolling are also appreciated.
> > > 
> > > I think I only want this for scroll-{up,down} and
> > > scroll-other-window{,-down} but possibly it would make sense for other
> > > commands which I don't know.
> > > 
> > > (I would file a bug requesting this feature, but scrolling is so
> > > fundamental that perhaps this is already supported by some combination
> > > of features which I don't know)
> > 
> > Have you tried scroll-lock-mode?
> 
> Yes, it's nice, but I also want the normal scroll-{up,down} commands to
> work.
> 
> I think scroll-lock-mode could do with a more convenient default
> binding, also.  A lot of programmers, including me, have keyboards which
> don't have a scroll lock key...

A keyboard without a ScrollLock key?  That's very strange indeed.

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

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Mon, 31 Jul 2023 16:18:15 -0400
> 
> 
> After I use scroll-up or scroll-down, I want to start reading the new
> text on the screen.  But it's easy to lose track of where the new text
> start, especially with larger values of next-screen-context-lines.
> 
> So, I would like scrolling to move point to the division between old and
> new text.  Then the location of the cursor will help me keep track of
> which text is new and which text is old.

I don't understand, because what you want happens here by default:
scrolling always puts at the top of the window the first line of those
which constitute next-screen-context-lines.  So, for example, if you
have next-screen-context-lines set to 5, C-v will put the 5th line
from the window's bottom at the top screen line.

If by "new text start" you mean the first line that was not visible in
the window before C-v, then set scroll-margin to the value of
next-screen-context-lines, and then Emacs will put point at that first
new line.

Is that what you want?

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: Mon, 31 Jul 2023 16:18:15 -0400
>> 
>> 
>> After I use scroll-up or scroll-down, I want to start reading the new
>> text on the screen.  But it's easy to lose track of where the new text
>> start, especially with larger values of next-screen-context-lines.
>> 
>> So, I would like scrolling to move point to the division between old and
>> new text.  Then the location of the cursor will help me keep track of
>> which text is new and which text is old.
>
> I don't understand, because what you want happens here by default:
> scrolling always puts at the top of the window the first line of those
> which constitute next-screen-context-lines.  So, for example, if you
> have next-screen-context-lines set to 5, C-v will put the 5th line
> from the window's bottom at the top screen line.

Ah, that's not quite what I mean...

> If by "new text start" you mean the first line that was not visible in
> the window before C-v, then set scroll-margin to the value of
> next-screen-context-lines, and then Emacs will put point at that first
> new line.
>
> Is that what you want?

Yes, that's exactly what I mean and want!  Perfect, and very clever!
That indeed moves point to the division between old and new text!

Ah, but there's a missing feature... I'd like it to also work as I
described when I use scrolling with a prefix argument.  That is, it
should move point to the division between old and new text even then.

So M-5 C-v would move point to 5 lines from the end of the buffer.
scroll-margin might interfere, but I still would want point to be at the
division between old and new text.

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

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Tue, 01 Aug 2023 10:50:48 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > If by "new text start" you mean the first line that was not visible in
> > the window before C-v, then set scroll-margin to the value of
> > next-screen-context-lines, and then Emacs will put point at that first
> > new line.
> >
> > Is that what you want?
> 
> Yes, that's exactly what I mean and want!  Perfect, and very clever!
> That indeed moves point to the division between old and new text!
> 
> Ah, but there's a missing feature... I'd like it to also work as I
> described when I use scrolling with a prefix argument.  That is, it
> should move point to the division between old and new text even then.
> 
> So M-5 C-v would move point to 5 lines from the end of the buffer.
> scroll-margin might interfere, but I still would want point to be at the
> division between old and new text.

When you scroll by a small number of lines, Emacs generally doesn't
move point at all, unless it has to.  And in that case, what exactly
is "new text"? it's basically undefined.

IOW, scrolling by single lines or a small number of lines is very
similar to scrolling with down-arrow or up-arrow, and those already
behave like you want.  So why not use arrows instead?

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: Tue, 01 Aug 2023 10:50:48 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > If by "new text start" you mean the first line that was not visible in
>> > the window before C-v, then set scroll-margin to the value of
>> > next-screen-context-lines, and then Emacs will put point at that first
>> > new line.
>> >
>> > Is that what you want?
>> 
>> Yes, that's exactly what I mean and want!  Perfect, and very clever!
>> That indeed moves point to the division between old and new text!
>> 
>> Ah, but there's a missing feature... I'd like it to also work as I
>> described when I use scrolling with a prefix argument.  That is, it
>> should move point to the division between old and new text even then.
>> 
>> So M-5 C-v would move point to 5 lines from the end of the buffer.
>> scroll-margin might interfere, but I still would want point to be at the
>> division between old and new text.
>
> When you scroll by a small number of lines, Emacs generally doesn't
> move point at all, unless it has to.  And in that case, what exactly
> is "new text"? it's basically undefined.

Yes, that's fair.  Probably I don't really need this.

An issue with a solution based on scroll-margin is that scroll-margin
applies even when at the end of the buffer.  I'd like to be able to have
the end of the buffer at the end of the window, to maximize the amount
of content on-screen at a time.

In particular comint buffers, like async-shell-command and compilation
and shell-mode, become quite ugly with scroll-margin on, since in such
buffers one is generally always at the end of the buffer.

Is there a way to teach scroll-margin to not do automatic scrolling when
point is near the end of the buffer?

> IOW, scrolling by single lines or a small number of lines is very
> similar to scrolling with down-arrow or up-arrow, and those already
> behave like you want.  So why not use arrows instead?

With the arrows I would have to move point to the top or end of the
screen before scrolling, which is annoying.

Also, arrows move point, and it might be nice to be able to scroll
without moving point.

scroll-up-line and scroll-down-line would work well for me, but they
don't have key bindings by default.  If they did, I'd use them.

Maybe we should add some?  I don't know what good bindings would be.

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

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Tue, 01 Aug 2023 14:09:47 -0400
> 
> An issue with a solution based on scroll-margin is that scroll-margin
> applies even when at the end of the buffer.  I'd like to be able to have
> the end of the buffer at the end of the window, to maximize the amount
> of content on-screen at a time.
> 
> In particular comint buffers, like async-shell-command and compilation
> and shell-mode, become quite ugly with scroll-margin on, since in such
> buffers one is generally always at the end of the buffer.
> 
> Is there a way to teach scroll-margin to not do automatic scrolling when
> point is near the end of the buffer?

You _can_ have EOB at the end of the window, you just cannot move
point into the margin without causing a scroll.

> > IOW, scrolling by single lines or a small number of lines is very
> > similar to scrolling with down-arrow or up-arrow, and those already
> > behave like you want.  So why not use arrows instead?
> 
> With the arrows I would have to move point to the top or end of the
> screen before scrolling, which is annoying.

Nothing 2 or 3 C-l's cannot fix, right?

> Also, arrows move point, and it might be nice to be able to scroll
> without moving point.

Scrolling by a small number of lines will eventually move point as
well.

> scroll-up-line and scroll-down-line would work well for me, but they
> don't have key bindings by default.  If they did, I'd use them.

I have these since about forever:

  (global-set-key "\M-z" (function (lambda () (interactive) (scroll-down 1))))
  (global-set-key "\C-z" (function (lambda () (interactive) (scroll-up 1))))

But I don't see a need to force my preferences on everyone else,
especially since C-z has a useful binding which many prefer to keep.

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: Tue, 01 Aug 2023 14:09:47 -0400
>> 
>> An issue with a solution based on scroll-margin is that scroll-margin
>> applies even when at the end of the buffer.  I'd like to be able to have
>> the end of the buffer at the end of the window, to maximize the amount
>> of content on-screen at a time.
>> 
>> In particular comint buffers, like async-shell-command and compilation
>> and shell-mode, become quite ugly with scroll-margin on, since in such
>> buffers one is generally always at the end of the buffer.
>> 
>> Is there a way to teach scroll-margin to not do automatic scrolling when
>> point is near the end of the buffer?
>
> You _can_ have EOB at the end of the window, you just cannot move
> point into the margin without causing a scroll.

Sure.  So I can have either point at EOB, or EOB at the end of the
window, but not both at the same time.  Which is bad for comint buffers,
since they usually have point at EOB.

I think this would be a good thing to improve: supporting this
capability in scroll-margin.  Unless, it already exists somehow?

>> > IOW, scrolling by single lines or a small number of lines is very
>> > similar to scrolling with down-arrow or up-arrow, and those already
>> > behave like you want.  So why not use arrows instead?
>> 
>> With the arrows I would have to move point to the top or end of the
>> screen before scrolling, which is annoying.
>
> Nothing 2 or 3 C-l's cannot fix, right?

M-r rather than C-l, (C-l would defeat the point), but nevertheless
having to hit M-r 2 or 3 times before scrolling for just a few lines is
annoying.

>> Also, arrows move point, and it might be nice to be able to scroll
>> without moving point.
>
> Scrolling by a small number of lines will eventually move point as
> well.
>
>> scroll-up-line and scroll-down-line would work well for me, but they
>> don't have key bindings by default.  If they did, I'd use them.
>
> I have these since about forever:
>
>   (global-set-key "\M-z" (function (lambda () (interactive) (scroll-down 1))))
>   (global-set-key "\C-z" (function (lambda () (interactive) (scroll-up 1))))
>
> But I don't see a need to force my preferences on everyone else,
> especially since C-z has a useful binding which many prefer to keep.

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

[Spencer Baugh]

Spencer Baugh <sbaugh@janestreet.com> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>>> From: Spencer Baugh <sbaugh@janestreet.com>
>>> Date: Tue, 01 Aug 2023 14:09:47 -0400
>>> 
>>> An issue with a solution based on scroll-margin is that scroll-margin
>>> applies even when at the end of the buffer.  I'd like to be able to have
>>> the end of the buffer at the end of the window, to maximize the amount
>>> of content on-screen at a time.
>>> 
>>> In particular comint buffers, like async-shell-command and compilation
>>> and shell-mode, become quite ugly with scroll-margin on, since in such
>>> buffers one is generally always at the end of the buffer.
>>> 
>>> Is there a way to teach scroll-margin to not do automatic scrolling when
>>> point is near the end of the buffer?
>>
>> You _can_ have EOB at the end of the window, you just cannot move
>> point into the margin without causing a scroll.
>
> Sure.  So I can have either point at EOB, or EOB at the end of the
> window, but not both at the same time.  Which is bad for comint buffers,
> since they usually have point at EOB.
>
> I think this would be a good thing to improve: supporting this
> capability in scroll-margin.  Unless, it already exists somehow?

It occurs to me that one way to do this is to disallow Emacs from
scrolling past the end of a buffer.  The default behavior is that with
C-l one can scroll past the end of a buffer, so there's empty space
displayed on screen.  But maybe there's a way to disallow that, so the
last line of the buffer is never above the last line of the window.

Is there a way to get Emacs to do that?  Seems like the kind of thing
someone would have implemented at some point.

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

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Thu, 03 Aug 2023 15:58:49 -0400
> 
> > Sure.  So I can have either point at EOB, or EOB at the end of the
> > window, but not both at the same time.  Which is bad for comint buffers,
> > since they usually have point at EOB.
> >
> > I think this would be a good thing to improve: supporting this
> > capability in scroll-margin.  Unless, it already exists somehow?
> 
> It occurs to me that one way to do this is to disallow Emacs from
> scrolling past the end of a buffer.  The default behavior is that with
> C-l one can scroll past the end of a buffer, so there's empty space
> displayed on screen.  But maybe there's a way to disallow that, so the
> last line of the buffer is never above the last line of the window.
> 
> Is there a way to get Emacs to do that?  Seems like the kind of thing
> someone would have implemented at some point.

We have this only for scrolling with the scroll bar: see
scroll-bar-adjust-thumb-portion.  Implementing this for every possible
kind of scrolling would need changes to C code, I think, since
scrolling is actually performed by the display engine.  Suggest to
file a feature-request bug report, and patches are welcome.

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

[Emanuel Berg]

Eli Zaretskii wrote:

>> Is there a way to get Emacs to do that? Seems like the kind
>> of thing someone would have implemented at some point.
>
> We have this only for scrolling with the scroll bar: see
> scroll-bar-adjust-thumb-portion. Implementing this for every
> possible kind of scrolling would need changes to C code,
> I think, since scrolling is actually performed by the
> display engine.

If one can get the state of scrolling in a window in Elisp one
could solve this in Elisp only since then one could write
a new scroll function on top of the old, and what it would do
is - based on that information - it would either scroll
normally or not call the function at all, if scrolling was
determined not to make any sense.

But I don't know if such data is available on the Lisp side,
if it is, I for one haven't found it ...

-- 
underground experts united
https://dataswamp.org/~incal

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Sun, 06 Aug 2023 22:02:18 +0200
> 
> Eli Zaretskii wrote:
> 
> > We have this only for scrolling with the scroll bar: see
> > scroll-bar-adjust-thumb-portion. Implementing this for every
> > possible kind of scrolling would need changes to C code,
> > I think, since scrolling is actually performed by the
> > display engine.
> 
> If one can get the state of scrolling in a window in Elisp one
> could solve this in Elisp only since then one could write
> a new scroll function on top of the old, and what it would do
> is - based on that information - it would either scroll
> normally or not call the function at all, if scrolling was
> determined not to make any sense.

I think your mental model of how scrolling works in Emacs is not
accurate.  What do you think "scrolling functions" do in Emacs?

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

[Emanuel Berg]

Eli Zaretskii wrote:

>>> We have this only for scrolling with the scroll bar: see
>>> scroll-bar-adjust-thumb-portion. Implementing this for
>>> every possible kind of scrolling would need changes to
>>> C code, I think, since scrolling is actually performed by
>>> the display engine.
>> 
>> If one can get the state of scrolling in a window in Elisp
>> one could solve this in Elisp only since then one could
>> write a new scroll function on top of the old, and what it
>> would do is - based on that information - it would either
>> scroll normally or not call the function at all, if
>> scrolling was determined not to make any sense.
>
> I think your mental model of how scrolling works in Emacs is
> not accurate. [...]

That can be helped,

(defun scroll-up-1 ()
  (interactive)
  (scroll-down 1) )

(defun scroll-down-1 ()
  (interactive)
  (scroll-up 1) )

-- 
underground experts united
https://dataswamp.org/~incal

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Wed, 09 Aug 2023 22:59:22 +0200
> 
> Eli Zaretskii wrote:
> 
> > I think your mental model of how scrolling works in Emacs is
> > not accurate. [...]
> 
> That can be helped,
> 
> (defun scroll-up-1 ()
>   (interactive)
>   (scroll-down 1) )
> 
> (defun scroll-down-1 ()
>   (interactive)
>   (scroll-up 1) )

I asked what you thought happens in Emacs as part of the call to
scroll-down.  If you think that function actually scrolls the text in
the window, then that's not what happens in reality.  The scrolling is
performed as part of redisplay, after scroll-up exits.

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

[Emanuel Berg]

Eli Zaretskii wrote:

>>> I think your mental model of how scrolling works in Emacs
>>> is not accurate. [...]
>> 
>> That can be helped,
>> 
>> (defun scroll-up-1 ()
>>   (interactive)
>>   (scroll-down 1) )
>> 
>> (defun scroll-down-1 ()
>>   (interactive)
>>   (scroll-up 1) )
>
> I asked what you thought happens in Emacs as part of the
> call to scroll-down. If you think that function actually
> scrolls the text in the window, then that's not what happens
> in reality. The scrolling is performed as part of redisplay,
> after scroll-up exits.

But it can still be controlled from Elisp. We would have
another function around the scroll function, and that other
function would be used instead. Normally it would just call
the scroll function. Normally - but not always :)

-- 
underground experts united
https://dataswamp.org/~incal

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Thu, 10 Aug 2023 20:06:23 +0200
> 
> Eli Zaretskii wrote:
> 
> >>> I think your mental model of how scrolling works in Emacs
> >>> is not accurate. [...]
> >> 
> >> That can be helped,
> >> 
> >> (defun scroll-up-1 ()
> >>   (interactive)
> >>   (scroll-down 1) )
> >> 
> >> (defun scroll-down-1 ()
> >>   (interactive)
> >>   (scroll-up 1) )
> >
> > I asked what you thought happens in Emacs as part of the
> > call to scroll-down. If you think that function actually
> > scrolls the text in the window, then that's not what happens
> > in reality. The scrolling is performed as part of redisplay,
> > after scroll-up exits.
> 
> But it can still be controlled from Elisp. We would have
> another function around the scroll function, and that other
> function would be used instead. Normally it would just call
> the scroll function. Normally - but not always :)

We've lost context.  This sub-thread began when you said:

  If one can get the state of scrolling in a window in Elisp one
  could solve this in Elisp only since then one could write
  a new scroll function on top of the old, and what it would do
  is - based on that information - it would either scroll
  normally or not call the function at all, if scrolling was
  determined not to make any sense.

So now please explain what you mean by "the state of scrolling" and
how would you determine that "scrolling does not make any sense"?

My point is that "the state of scrolling" (at least my interpretation
of that) is only known when the scrolling was already done, by which
time it's too late to try to figure out whether "scrolling does not
make any sense".  That's because Lisp code doesn't compute how to
scroll the window, and thus doesn't know what would scrolling yield.
The actual scrolling is done by the display engine, in C code.

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

[Emanuel Berg]

Eli Zaretskii wrote:

>   If one can get the state of scrolling in a window in Elisp
>   one could solve this in Elisp only since then one could
>   write a new scroll function on top of the old, and what it
>   would do is - based on that information - it would either
>   scroll normally or not call the function at all, if
>   scrolling was determined not to make any sense.
>
> So now please explain what you mean by "the state of
> scrolling" and how would you determine that "scrolling does
> not make any sense"?

For example, in this very window I look at right now, the
whole lower part of the buffer is displayed - it says "Bottom"
in the mode bar - still I can scroll down even more, and - what
Emacs calls scroll "up" BTW - by evaluating this

(scroll-up 1)

to just show more and more empty space.

If we can find out from Elisp that we are already at the
bottom, we wouldn't do that in a supposed wrapper function.
I don't know how to find that out but if possible and anyone
knows do tell as then I could write the function easily that
I had in mind and show you.

-- 
underground experts united
https://dataswamp.org/~incal

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Fri, 11 Aug 2023 14:19:23 +0200
> 
> Eli Zaretskii wrote:
> 
> > So now please explain what you mean by "the state of
> > scrolling" and how would you determine that "scrolling does
> > not make any sense"?
> 
> For example, in this very window I look at right now, the
> whole lower part of the buffer is displayed - it says "Bottom"
> in the mode bar - still I can scroll down even more, and - what
> Emacs calls scroll "up" BTW - by evaluating this
> 
> (scroll-up 1)
> 
> to just show more and more empty space.
> 
> If we can find out from Elisp that we are already at the
> bottom, we wouldn't do that in a supposed wrapper function.
> I don't know how to find that out but if possible and anyone
> knows do tell as then I could write the function easily that
> I had in mind and show you.

You can find it in the simple cases like the one you describe, but not
in general.  For example, if you scroll by N window-fulls , it is
usually impossible to know in advance whether the last window will
show EOB with empty space after it.

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

[Emanuel Berg]

Eli Zaretskii wrote:

> You can find it in the simple cases like the one you
> describe, but not in general. For example, if you scroll by
> N window-fulls , it is usually impossible to know in advance
> whether the last window will show EOB with empty space
> after it.

Only one thing to do then, get the scroll state from C to
Lisp, then do the check in Lisp, then sometimes make the
scroll in C ...

-- 
underground experts united
https://dataswamp.org/~incal

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Fri, 11 Aug 2023 21:00:14 +0200
> 
> Eli Zaretskii wrote:
> 
> > You can find it in the simple cases like the one you
> > describe, but not in general. For example, if you scroll by
> > N window-fulls , it is usually impossible to know in advance
> > whether the last window will show EOB with empty space
> > after it.
> 
> Only one thing to do then, get the scroll state from C to
> Lisp, then do the check in Lisp, then sometimes make the
> scroll in C ...

You can't.  I tried to explain why.

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

[Emanuel Berg]

Eli Zaretskii wrote:

> You can find it in the simple cases like the one you
> describe, but not in general. For example, if you scroll by
> N window-fulls

Actually depending on what data is available maybe that can be
computed quite easily, by adding N, divide by the number of
lines visibly etc, simple arithmetics.

But again it all depends what data is available?

Like right now for example! Where it should scroll according
to the suggestion, any why not (why should it)? But agreed,
I never thought about it until now! :)

-- 
underground experts united
https://dataswamp.org/~incal

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Fri, 11 Aug 2023 21:04:15 +0200
> 
> Eli Zaretskii wrote:
> 
> > You can find it in the simple cases like the one you
> > describe, but not in general. For example, if you scroll by
> > N window-fulls
> 
> Actually depending on what data is available maybe that can be
> computed quite easily, by adding N, divide by the number of
> lines visibly etc, simple arithmetics.

You forgot that Emacs supports variable fonts and images embedded in
text since 2001...  So the simple arithmetics doesn't really work,
except in some cases where you are lucky.

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

[Emanuel Berg]

Eli Zaretskii wrote:

>> Actually depending on what data is available maybe that can
>> be computed quite easily, by adding N, divide by the number
>> of lines visibly etc, simple arithmetics.
>
> You forgot that Emacs supports variable fonts and images
> embedded in text since 2001... So the simple arithmetics
> doesn't really work, except in some cases where you
> are lucky.

It is pointless to discuss what can ore cannot be done until
it is clear what data is or can be available. Since it says
"Bottom" in my mode bar that data is clearly available
somewhere, and it is actually everything needed in this case
to prevent or allow scrolling ....


-- 
underground experts united
https://dataswamp.org/~incal

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Sat, 12 Aug 2023 17:35:10 +0200
> 
> Since it says "Bottom" in my mode bar that data is clearly available
> somewhere, and it is actually everything needed in this case to
> prevent or allow scrolling ....

That data is available, but _after_ the scroll was already done.

Just to remind you, both the scrolling of the window and the display
of the mode line (the one that says "Bottom") is the job of the
display engine, and by the time it displays the mode line, it already
knows the results of scrolling the window.

Your idea, by contrast, was to know the results of scrolling _before_
scrolling, and that is what I'm trying to explain to you.

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

[Emanuel Berg]

Eli Zaretskii wrote:

> That data is available, but _after_ the scroll was already
> done. [...] Your idea, by contrast, was to know the results
> of scrolling _before_ scrolling

It would be computed from the current state plus the intended
scrolling, BTW the data isn't what is currently returned
by scrolling.

No, for example, by opening this very buffer, Emacs already
knows its state, since it displays "All" in the mode bar (and
I didn't scroll).

So it is already there. Somewhere!

-- 
underground experts united
https://dataswamp.org/~incal

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Sun, 20 Aug 2023 05:38:56 +0200
> 
> Eli Zaretskii wrote:
> 
> > That data is available, but _after_ the scroll was already
> > done. [...] Your idea, by contrast, was to know the results
> > of scrolling _before_ scrolling
> 
> It would be computed from the current state plus the intended
> scrolling, BTW the data isn't what is currently returned
> by scrolling.

I didn't say _by_ scrolling, I said _after_ scrolling.

> No, for example, by opening this very buffer, Emacs already
> knows its state, since it displays "All" in the mode bar (and
> I didn't scroll).
> 
> So it is already there. Somewhere!

Yes, but _after_ the display, not before.

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

[Emanuel Berg]

Eli Zaretskii wrote:

>> It would be computed from the current state plus the
>> intended scrolling, BTW the data isn't what is currently
>> returned by scrolling.
>
> I didn't say _by_ scrolling, I said _after_ scrolling.
>
>> No, for example, by opening this very buffer, Emacs already
>> knows its state, since it displays "All" in the mode bar (and
>> I didn't scroll).
>> 
>> So it is already there. Somewhere!
>
> Yes, but _after_ the display, not before.

It is available before scrolling, like now it says 4%.
The next time I execute a scroll function by hitting a key,
that function could look at that data and use it to determine
if scrolling should take place, and only then do it.

Just now I'm scrolling some more, and now it says "Bottom" in
the mode bar instead. I am able to scroll more, but the
function I describe would in this, changed situation see that
it already is at the bottom and therefore not scroll.

-- 
underground experts united
https://dataswamp.org/~incal

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

[Eli Zaretskii]

> From: Emanuel Berg <incal@dataswamp.org>
> Date: Tue, 22 Aug 2023 21:41:05 +0200
> 
> Eli Zaretskii wrote:
> 
> >> No, for example, by opening this very buffer, Emacs already
> >> knows its state, since it displays "All" in the mode bar (and
> >> I didn't scroll).
> >> 
> >> So it is already there. Somewhere!
> >
> > Yes, but _after_ the display, not before.
> 
> It is available before scrolling, like now it says 4%.
> The next time I execute a scroll function by hitting a key,
> that function could look at that data and use it to determine
> if scrolling should take place, and only then do it.

You once again lost the context.  Your proposed solution required to
have this information _after_ the scroll command, to know where the
display will end up after performing the scrolling.  For that purpose,
it is not very useful to know where you are _before_ scrolling.

> Just now I'm scrolling some more, and now it says "Bottom" in
> the mode bar instead. I am able to scroll more, but the
> function I describe would in this, changed situation see that
> it already is at the bottom and therefore not scroll.

These indications are updated after two things happen, one after the
other:

  . the scroll command determines where to locate the window-start
    position
  . the following redisplay cycle actually scrolls the text to obey
    what the scroll command determined, determines the window's end
    position, and updates the mode-line indication like "Bottom"

Your proposed solution was to inject some logic _between_ those two,
and the position of the end of the window is not yet known at that
point.

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

[Emanuel Berg]

Eli Zaretskii wrote:

> You once again lost the context. Your proposed solution
> required to have this information _after_ the scroll
> command, to know where the display will end up after
> performing the scrolling. For that purpose, it is not very
> useful to know where you are _before_ scrolling.

The information is always available, before and after. You can
see it for yourself in the mode bar. If it says "All" or
"Bottom", don't scroll.

-- 
underground experts united
https://dataswamp.org/~incal

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: Mon, 31 Jul 2023 16:18:15 -0400
>> 
>> 
>> After I use scroll-up or scroll-down, I want to start reading the new
>> text on the screen.  But it's easy to lose track of where the new text
>> start, especially with larger values of next-screen-context-lines.
>> 
>> So, I would like scrolling to move point to the division between old and
>> new text.  Then the location of the cursor will help me keep track of
>> which text is new and which text is old.
>
> I don't understand, because what you want happens here by default:
> scrolling always puts at the top of the window the first line of those
> which constitute next-screen-context-lines.  So, for example, if you
> have next-screen-context-lines set to 5, C-v will put the 5th line
> from the window's bottom at the top screen line.
>
> If by "new text start" you mean the first line that was not visible in
> the window before C-v, then set scroll-margin to the value of
> next-screen-context-lines, and then Emacs will put point at that first
> new line.
>
> Is that what you want?

After using it for a bit, I ended up deciding that the other effects of
scroll-margin were too annoying, so I turned it off again.
(scroll-margin interacts poorly with C-M-l for example, because C-M-l
puts the start of the function at the top of the screen, but actually
moving point to the start of the function then causes annoying
scrolling.)

So I still want some other way to achieve this behavior which doesn't
change scroll-margin.

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?

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

[Eli Zaretskii]

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

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.

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.

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

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Wed, 16 Aug 2023 13:55:42 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> (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.

That's what I meant: only 1 widow-full scroll.

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

Either setting next-screen-context-lines to 1 should do what you want,
or I still don't understand what you want when scrolling by more than
one window-full.

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 13:55:42 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> >> (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.
>
> That's what I meant: only 1 widow-full scroll.
>
>> 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.
>
> Either setting next-screen-context-lines to 1 should do what you want,
> or I still don't understand what you want when scrolling by more than
> one window-full.

Well, yes, if next-screen-context-lines is 1 then
window-end-before-scroll and window-start-after-scroll are the same.  So
that trivially provides the behavior I described, I suppose...

But I want the behavior I described even when next-screen-context-lines
is greater than 1.  (I personally set it to 10.)  In that case,
window-end-before-scroll and window-start-after-scroll aren't the same,
and Emacs doesn't behave how I described.

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

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Wed, 16 Aug 2023 16:32:22 -0400
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Either setting next-screen-context-lines to 1 should do what you want,
> > or I still don't understand what you want when scrolling by more than
> > one window-full.
> 
> Well, yes, if next-screen-context-lines is 1 then
> window-end-before-scroll and window-start-after-scroll are the same.  So
> that trivially provides the behavior I described, I suppose...
> 
> But I want the behavior I described even when next-screen-context-lines
> is greater than 1.  (I personally set it to 10.)  In that case,
> window-end-before-scroll and window-start-after-scroll aren't the same,
> and Emacs doesn't behave how I described.

But in that case I don't have a clear idea how to incorporate what you
want in the way scrolling is implemented in Emacs.  The scrolling
functions usually don't move point, they just set the window-start
position according to the scroll-command argument and relevant user
options.  The actual scrolling is done by the display engine during
the next redisplay cycle, and that either leaves point where it was
(if point is still visible) or moves it into the viewport.  This
scrolling is general display feature, it can happen even if something
other than a scrolling command caused it.  Thus, knowing when to move
point to a particular place is not trivial, and would need some
variable exposed to Lisp or something like that, and then some
non-trivial logic to use that.

It is also not clear whether you want this only for scroll commands or
also for other causes of scrolling the window.

Maybe you could do something similar to how
scroll-preserve-screen-position works.

Feel free to work on this, of course.

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 16:32:22 -0400
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > Either setting next-screen-context-lines to 1 should do what you want,
>> > or I still don't understand what you want when scrolling by more than
>> > one window-full.
>> 
>> Well, yes, if next-screen-context-lines is 1 then
>> window-end-before-scroll and window-start-after-scroll are the same.  So
>> that trivially provides the behavior I described, I suppose...
>> 
>> But I want the behavior I described even when next-screen-context-lines
>> is greater than 1.  (I personally set it to 10.)  In that case,
>> window-end-before-scroll and window-start-after-scroll aren't the same,
>> and Emacs doesn't behave how I described.
>
> But in that case I don't have a clear idea how to incorporate what you
> want in the way scrolling is implemented in Emacs.  The scrolling
> functions usually don't move point, they just set the window-start
> position according to the scroll-command argument and relevant user
> options.  The actual scrolling is done by the display engine during
> the next redisplay cycle, and that either leaves point where it was
> (if point is still visible)

The code I'd want to modify is...

> or moves it into the viewport.

exactly this code.  e.g. in window_scroll_line_based there's calls to
Fvertical_motion, I'd want to add more logic just before those calls.
I'd need to do the same for window_scroll_pixel_based.

> This scrolling is general display feature, it can happen even if
> something other than a scrolling command caused it.  Thus, knowing
> when to move point to a particular place is not trivial, and would
> need some variable exposed to Lisp or something like that, and then
> some non-trivial logic to use that.

Hm, not sure why I'd need logic in Lisp, if I take the approach I just
mentioned.  (We'd need a defcustom of course to control the behavior,
but other than that.)

> It is also not clear whether you want this only for scroll commands or
> also for other causes of scrolling the window.
>
> Maybe you could do something similar to how
> scroll-preserve-screen-position works.
>
> Feel free to work on this, of course.

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

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Date: Thu, 17 Aug 2023 08:19:55 -0400
> 
> > or moves it into the viewport.
> 
> exactly this code.  e.g. in window_scroll_line_based there's calls to
> Fvertical_motion, I'd want to add more logic just before those calls.
> I'd need to do the same for window_scroll_pixel_based.

That'd not be my first choice.  I'd actually suggest to study how
scroll-preserve-screen-position is implemented, and do something
similar.

> > This scrolling is general display feature, it can happen even if
> > something other than a scrolling command caused it.  Thus, knowing
> > when to move point to a particular place is not trivial, and would
> > need some variable exposed to Lisp or something like that, and then
> > some non-trivial logic to use that.
> 
> Hm, not sure why I'd need logic in Lisp

If that variable would hold the position of point for after the
scroll, you'd need some logic to set the value.

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

[Emanuel Berg]

Spencer Baugh wrote:

> After I use scroll-up or scroll-down, I want to start
> reading the new text on the screen. But it's easy to lose
> track of where the new text start, especially with larger
> values of next-screen-context-lines.

Don't know what you mean by the new text but here is some work
on scrolling, maybe you can make use of it:

  https://dataswamp.org/~incal/emacs-init/scroll.el

-- 
underground experts united
https://dataswamp.org/~incal