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

Previous Next

Full log

View this message in rfc822 format

From: Michael Heerdegen <michael_heerdegen <at> web.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: larsi <at> gnus.org, esabof <at> gmail.com, 14582 <at> debbugs.gnu.org
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

Eli Zaretskii <eliz <at> 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.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.