GNU bug report logs - #56561
29.0.50; Infloop in try_window

Previous Next

Full log

View this message in rfc822 format

From: Po Lu <luangruo <at> yahoo.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: mwd <at> md5i.com, 56561 <at> debbugs.gnu.org
Subject: bug#56561: 29.0.50; Infloop in try_window
Date: Sat, 16 Jul 2022 11:11:52 +0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> On second thought, I take this back.  I don't see how we could have a
> blank tooltip.  We call try_window just so we could compute the size
> of the text in it, which then allows us to know the size of the
> tooltip.  The situation where nrows_scale_factor is increased happens
> when we get to the bottom of the window, which for a tooltip means we
> already laid out all the text and are just producing empty glyph rows
> beyond the end of the text.  ncols_scale_factor could theoretically
> happen before we reach the end of the text, but I'd like to see
> something like that happening before I believe it; and even if it does
> happen in the very first line, the tooltip will not be empty, just
> truncated.

No, we call try_window to generate the window contents, and then call
update_single_window followed by flush_frame to immediately flush the
contents to display.

This is because redisplay actually cannot run by itself in some cases
where we do want tooltips to be displayed.

> We could add an assertion to verify that try_window gets to ZV in this
> case before it returns, if we want to be able to detect those cases.

This could still work.  I think `TRY_WINDOW_IGNORE_FONTS_CHANGE' means
the caller isn't ready for try_window to fail.

Previous Next

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