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: E Sabof <esabof@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   14582@debbugs.gnu.org
> Date: Mon, 31 Jan 2022 01:36:41 +0100
> 
> The effect is that the first visual line in the folded buffer looks like
> 
> ...
> 
> i.e. consists of just three eliding dots, but when I scroll up, I see
> that the dots belong to e.g.
> 
> (progn...)
> 
> I see that all the time when working with hideshow, and it's quite
> annoying.

After considering this for a while, I don't think it would be a good
idea to try to fix this on the level of the display engine.  The
reason is that there are gobs of Lisp programs out there playing all
kinds of tricks with overlays and invisible text and expecting Emacs
to heed those tricks, and so any change like the one suggested,
i.e. let the display engine disobey the window-start setting in this
situation, is definitely going to break some package, and probably a
lot of them.

Basically, we are being asked to introduce application-level logic
into the general-purpose parts of the display code: the application
sets the window-start at some place which happens to be a bad idea,
and wants the display engine to save the application from itself.  I
don't think it's TRT.  The application alone knows what would be a
good place for setting the window-start, and should avoid setting it
where the result will be sub-optimal.

If this issue causes trouble in hideshow or elsewhere, my suggestion
is to fix it in those packages instead.  It shouldn't be hard to know
whether a given buffer position is or isn't invisible, and move point
from there if so.