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

From: Michael Heerdegen <[email-masked]>
Date: Fri, 11 Feb 2022 05:42:44 +0100

Eli Zaretskii <[email-masked]> writes:

> That's not what make-window-start-visible means.  It means "if the
> current window-start is invisible, try to find an alternative
> window-start that would be visible, while still showing point".
>
> Your interpretation of the setting is simply impossible to implement:
> the display engine cannot possibly do anything to uncover the hidden
> window-start point without scrolling the window in some way.  So
> _something_ that was visible before must become invisible after,
> because we scroll the window.

I'm irritated that the newly chosen window-start can be after the
original position.  I don't know any use case where this is useful, and
it was only irritating whenever it happened in my test.  Is this
unavoidable?

BTW, why does the adjustment happen when I just move the cursor inside
the displayed window content without causing any display change?  The
new heuristic seems to depend on the value of `point' (I don't mean
values that would cause scrolling the normal way).

Thanks,

Michael.