bug-gnu-emacs
[Top][All Lists]
Advanced

[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: Michael Heerdegen
Subject: bug#14582: 24.3.50.1; Strange overlay behavior, when window-start is inside an overlay.
Date: Wed, 02 Feb 2022 02:12:03 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/29.0.50 (gnu/linux)

Eli Zaretskii <eliz@gnu.org> writes:

> Perhaps your mental model of redisplay is that it determines the
> window-start position _after_ it applies the various text properties
> and overlays, which affect what will be visible on display.  In which
> case it would have noticed that after hiding the function bodies the
> visual line will start at "(defun ...", and would therefore start the
> window's display there.

Yes, something like that.  At least, I would not expect that only a part
of a (visual) line is displayed, however that comes.

> hs-minor-mode _does_ know what effect it wants to produce, so it's
> hs-minor-mode that needs to adjust window-start if it happens to wind
> up in the part of text that is about to be hidden on display.

Let's extend the discussion to invisible text in general - hideshow is
only one application of invisible text.  Are there cases where the
current behavior makes sense and is expected?  More sense than the
behavior I expect?

I ask because you said that the display engine can't know the intention.
Does it have to?  Why can't the credo just be "always ensure complete
visual lines are displayed"?


Regards,

Michael.






reply via email to

[Prev in Thread] Current Thread [Next in Thread]