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 19:46:15 +0800
> 
> >> +@vindex keep-point-visible
> >> +  If @code{keep-point-visible} is nil, redisplay will not move recenter
> >> +the display when the window start is changed.
> >> +
> >> +@vindex scroll-move-point
> >> +  If @code{scroll-move-point} is nil, scrolling commands will not move
> >> +point to keep it inside the visible part of the window.
> 
> > Why do we need 2 flags?  Are they indeed orthogonal, or can we have a
> > single variable (perhaps with more than 2 states)?
> 
> The first flag controls the behaviour of redisplay, while the second
> controls that of the scrolling commands, so I think they are orthogonal.

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?

> >> @@ -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;
> 
> > What does it mean when you set the w->start point, but do NOT set the
> > w->force_start flag?
> 
> w->force_start will result in point being constrained inside window
> start by the code under force_start: in redisplay_window.

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?

> >> +      /* Make sure beg_unchanged and end_unchanged are up to date.  Do it
> >> +   only if buffer has really changed.  The reason is that the gap is
> >> +   initially at Z for freshly visited files.  The code below would
> >> +   set end_unchanged to 0 in that case.  */
> >> +      if (GPT - BEG < BEG_UNCHANGED)
> >> +  BEG_UNCHANGED = GPT - BEG;
> >> +      if (Z - GPT < END_UNCHANGED)
> >> +  END_UNCHANGED = Z - GPT;
> 
> > I'm not sure I understand this part.  Why do you need to change the
> > values of BEG_UNCHANGED and END_UNCHANGED -- those are supposed to be
> > changed only by code that modifies the buffer text.
> 
> I saw the code do that in try_window_id, so even though I didn't really
> understand it I thought it would be safer to do that here as well.

But you aren't going to do anything that try_window_id does, are you?

> > You want to display window around the change, but not bring point
> > there?  Is that a good idea?
> 
> Yes, IMO.  If the change is actually at point, then the window will be
> recentered around point by the `PT != w->last_point' conditional.
> 
> Otherwise, such surprising changes to point would be unwanted.

No, I mean don't we want to force point to move to the locus of these
changes?  I thought other applications did that.

> > Why do we need this maybe_try_window stuff?  It seems to repeat
> > existing code, doesn't it?
> 
> It does.  There was a reason I put it there last December, but I can't
> remember it right now.

Too bad.