Re: Allowing point to be outside the window?

[Po Lu]

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.

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

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

No, so it's probably safe to remove then.  Thanks.

> 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"))