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

Previous Next

Full log

Message #106 received at 14582 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Michael Heerdegen <michael_heerdegen <at> web.de>
Cc: larsi <at> gnus.org, esabof <at> gmail.com, 14582 <at> debbugs.gnu.org
Subject: Re: bug#14582: 24.3.50.1; Strange overlay behavior, when
 window-start is inside an overlay.
Date: Thu, 10 Feb 2022 08:15:59 +0200

> From: Michael Heerdegen <michael_heerdegen <at> web.de>
> Cc: larsi <at> gnus.org,  esabof <at> gmail.com,  14582 <at> debbugs.gnu.org
> Date: Thu, 10 Feb 2022 02:07:19 +0100
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > Info buffers have a 'display' property whose value is a string at the
> > beginning of each node, and that 'display' property makes the window's
> > start point invisible.  So whenever Emacs can make the window-start
> > visible, it does.
> 
> But Emacs scrolls the first lines out of view: at the upper edge, less
> text is visible after the adjustment.  How does this make anything
> visible that had not been visible before?

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.

Previous Next

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