bug#56561: 29.0.50; Infloop in try_window

[Eli Zaretskii]

> From: Po Lu <luangruo@yahoo.com>
> Cc: mwd@md5i.com,  56561@debbugs.gnu.org
> Date: Sat, 16 Jul 2022 14:42:09 +0800
> 
> Hmm, right.  But what if Vx_max_tooltip_size makes the window too small
> to hold the entire tooltip?

Then it's what the user or the application who set the values wanted,
and we shouldn't override that.  And in this case having try_window
return zero is perfectly OK, btw, even if it didn't process through
ZV.

> > As for toolkits: we don't use this code when toolkit tooltips are
> > used.
> 
> I wasn't talking about X specifically.  The code in nsfns.m calls
> [NSWindow setFrame: display:], which can end up calling
> adjust_frame_size if NS decides for whatever reason to resize the
> tooltip frame.

Depending on the conditions when that resizing happens, it could
arguably be a bug, e.g. if x-max-tooltip-size restriction is
overruled.

> > That would trigger unnecessarily, creating false positives.
> 
> How so?  We pass TRY_WINDOW_IGNORE_FONTS_CHANGE, so try_window can only
> return 0 if the glyph matrices are too small.

The question is "small for what?"  If it is only too small to display
enough empty glyph rows, we don't care, since the tooltip will be
sized to accommodate for the text part only, and the empty glyph rows
will not be displayed anyway.

> > The situation that started this bug report is one such case: my fix
> > will cause try_window to return zero in that case.  But if the entire
> > text was processed and is in the glyph matrix, that zero return value
> > doesn't mean a failure.
> 
> That isn't what the comment above try_window says about its return
> value:
> 
>    Value is 1 if successful.  It is zero if fonts were loaded during
>    redisplay which makes re-adjusting glyph matrices necessary, and -1
>    if point would appear in the scroll margins.
>    (We check the former only if TRY_WINDOW_IGNORE_FONTS_CHANGE is
>    unset in FLAGS, and the latter only if TRY_WINDOW_CHECK_MARGINS is
>    set in FLAGS.)

I'm reading the code, not the commentary.  I will fix the commentary
to be more accurate: it doesn't take into account the special way we
invoke this function from x-show-tip.  Note that x-show-tip doesn't
check the return value, and never did, for that very reason.