[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is ins
From: |
Eli Zaretskii |
Subject: |
bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay. |
Date: |
Mon, 31 Jan 2022 21:08:33 +0200 |
> From: Michael Heerdegen <michael_heerdegen@web.de>
> Cc: larsi@gnus.org, esabof@gmail.com, 14582@debbugs.gnu.org
> Date: Mon, 31 Jan 2022 19:42:39 +0100
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > 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.
>
> There is a misunderstanding here: hideshow doesn't change window-start.
>
> What actually happens is: Elisp, be it hideshow or whatever, changes
> visibility of some part(s) of the buffer. Sometimes it can happen that
> the old window start position (in any window) is part of a fold
> (invisible region) afterwards. Then the issue I described occurs.
Then please provide a full, self-contained recipe starting from "emacs
-Q" that uses hideshow. The only recipe I saw and analyzed in this
bug was the original one, which did set window-start. Perhaps you are
talking about a different issue.