bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.

[Eli Zaretskii]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Fri, 04 Feb 2022 02:37:44 +0100
> 
> I played shortly with the new option enabled.  I didn't experience this
> issue, but in some situations redisplay seems to infloop.  Seems that
> happens when the first line is wrapped - at least I didn't see the same
> problem without wrapped lines.  Here is a reproducer for emacs -Q (just
> eval with M-:):
> 
> #+begin_src emacs-lisp
> (progn
>   (dotimes (_ 100) (insert "\
> \(defun foooooooooo (long-arg another-long-arg an-even-very-long-arg \
> and-one-more-arg)
>   1
>   2)\n"))
>   (setq make-window-start-visible t)
>   (goto-char (point-max))
>   (sit-for 1)
>   (scroll-down)
>   (sit-for 1)
>   (hs-minor-mode)
>   (hs-hide-all))
> #+end_src

Thanks, should be fixed now.

> BTW, I wondered - do we also have to care about window-end - or can
> the thing this report is about only happen for window-start?

window-end point is determined as side effect of successful complete
redisplay of a window, and cannot be determined before redisplay is
complete.  The window-end point isn't necessarily at the end of some
physical line, and it is by definition at the end of a visual line.
So I don't see why would we need to care about something similar
happening at the window's end.