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

[Eli Zaretskii <eliz@gnu.org>]

> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org,  esabof@gmail.com,  14582@debbugs.gnu.org
> Date: Wed, 09 Feb 2022 04:53:05 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > Neither do I, so there's something else at work here.
> 
> I failed to find a recipe in half an hour and gave up for now - instead
> I found one for a very similar case of unexpected auto-scrolling that
> only appears when the new feature is turned on.  Also seems to depend on
> the buffer contents.  Maybe it is related and a fix fixes the other
> thing, too.
> 
> emacs -Q
> 1 C-h i
> 2 move point to the beginning of one of the last visible lines.
>   no scrolling happens (good).
> 3 M-: (setq make-window-start-visible t) RET  => *info* buffer scrolled
> 
> If you scroll back so that (point-min) becomes visible and repeat step
> 2 any activation of the minibuffer, e.g. just hitting M-: or C-x k,
> scrolls the *info* buffer.
> 
> Doesn't happen in C-h n.  Dunno what makes the difference - the fact
> that *info* is narrowed or that different fonts are used.
> 
> Ah - wait, now I can reproduce the other thing, too:
> 
> M-:
> (progn
>   (setq-default display-time-interval 1.)
>   (setq display-time-format "%H:%M:%S")
>   (setq-default make-window-start-visible t)
>   (display-time-mode +1))
> RET
> C-h i
> [down] [down] not too fast ... until it scrolls

You asked for it.  Info buffers have a 'display' property whose value
is a string at the beginning of each node, and that 'display' property
makes the window's start point invisible.  So whenever Emacs can make
the window-start visible, it does.

IOW, here you have one example why the default way of handling
"hidden" window-start point is sometimes exactly what we want.

Bottom line: I advise against making this the default.