bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> Cc: mwd@md5i.com, 56561@debbugs.gnu.org
> Date: Fri, 15 Jul 2022 17:24:26 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Po Lu <luangruo@yahoo.com>
> > Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> > Date: Fri, 15 Jul 2022 21:54:24 +0800
> > 
> > BTW, I have a question about the fix: redisplay cannot run when a
> > tooltip is displayed as popup menu help-text, so adjust_glyph_matrix and
> > the subsequent try_window call that is required to generate the display
> > contents will not be called in time, leading to a blank tooltip.
> > 
> > The call could previously never fail, since the tooltip code specifies
> > TRY_WINDOW_IGNORE_FONTS_CHANGE.
> > 
> > Would it be appropriate to call adjust_frame_glyphs and try_window again
> > if this call to try_window in Fx_show_tip fails?
> 
> You mean, adjust_frame_glyphs, right?
> 
> We probably should do that

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.

So I cannot see how this case could produce an empty tooltip, and I
have hard time imagining how it could even produce a truncated text.
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.

> We need a recipe to trigger the reverse, to be able to test a
> solution.

That part is still true.