Re: Allowing point to be outside the window?

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: emacs-devel@gnu.org
> Date: Sun, 06 Feb 2022 20:21:11 +0800
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Since scrolling is basically implemented in redisplay, I don't think
> > this answers my question.
> >
> > Let's look at this from another aspect: which combinations of values
> > of these two variables make sense, and what would be the behavior
> > under each one of these reasonable combinations?
> 
> It makes sense to have `scroll-move-point' to t, and
> `keep-point-visible' set to nil or t, and `scroll-move-point' set to nil
> when `keep-point-visible' is nil.
> 
> The behaviour under the first and combinations would be that scrolling
> moves point to fit inside the visible portion of the buffer.  With the
> third, scrolling will not move the point at all.

So we have at most 3 states, and could have a single tri-state
variable.

And I question the validity of the combination scroll-move-point = nil
with keep-point-visible = t.  The problem with your implementation is
that scroll-move-point = nil disables scrolling in redisplay_window,
but scrolling there is used not necessarily as result of scrolling
commands, but also when redisplay_window decides that the optimal
method of updating a window is to scroll its previous contents.  Thus,
disabling scrolling on that level will cause confusing results,
because users will expect that to affect only scrolling commands: they
are unaware that redisplay sometimes scrolls the window for other
reasons.

> >> >> @@ -5659,8 +5660,9 @@ window_scroll_pixel_based (Lisp_Object window, 
> >> >> int n, bool whole, bool noerror)
> >> >>                   w->start_at_line_beg = true;
> >> >>                   wset_update_mode_line (w);
> >> >>                   /* Set force_start so that redisplay_window will run 
> >> >> the
> >> >> -                    window-scroll-functions.  */
> >> >> -                 w->force_start = true;
> >> >> +                    window-scroll-functions, unless scroll_move_point 
> >> >> is false,
> >> >> +                    in which case forcing the start will cause 
> >> >> recentering.  */
> >> >> +                 w->force_start = scroll_move_point;
> 
> > That doesn't really answer my question.  I was asking what is the
> > semantics of setting the window-start, but not the force_start flag?
> > What is expected from redisplay in this case? should it obey
> > window-start?
> 
> It's expected that it will obey window-start (unless some text changed
> before it, in which case it will recenter around the first change
> position.)

For that, you must set the force_start flag.  If you don't set it,
redisplay cannot know whether the value of w->start is just the result
of the previous redisplay cycle or was set by some user command which
wants to scroll the window.

Perhaps you want to explore using w->optional_new_start instead?

> > No, I mean don't we want to force point to move to the locus of these
> > changes?  I thought other applications did that.
> 
> They provide no way to make changes without point already being at the
> locus of the change.  (In which case it will be caught either by the `PT
> != w->last_point' conditional, and redisplay will recenter around point
> as usual, or if point did not move, then it will recenter around the
> change, which would be near the point in that case.)
> 
> IOW, there's no way in most other editors to do something like this:
> 
>   (save-excursion
>     (goto-char (point-min))
>     (insert "foo"))

Maybe so should we, at least as an option.