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: Fri, 11 Feb 2022 05:42:44 +0100

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

Previous Next

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