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

Previous Next

Full log

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

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

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: mwd <at> md5i.com,  56561 <at> debbugs.gnu.org
> Date: Sat, 16 Jul 2022 13:55:24 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > What I had in mind is an assertion in x-show-tip that the glyph matrix
> > produced by try_window includes all of the tooltip text, i.e. that
> > there's a glyph row there whose ends_at_zv_p flag is set.  This is an
> > indication that all of the text was processed and will appear in the
> > tooltip.
> >
> > Note that in the case in point this is precisely what's happened: the
> > entire text of the tip was processed and produced its glyphs, and the
> > problem happened while try_window was producing empty glyph rows
> > beyond ZV.
> 
> Thanks, but we can't guarantee that the tooltip frame's window is large
> enough to hold the entire contents of the tooltip buffer.  The size can
> be changed (on various different platforms) by the window manager or the
> toolkit.

If the window manager changes the size of the window, we won't know
that in try_window, because the code which creates the window-system
window runs _after_ try_window.  The dimensions of the Emacs window
for which we invoke try_window and of its frame are determined by our
code:

  if (CONSP (Vx_max_tooltip_size)
      && RANGED_FIXNUMP (1, XCAR (Vx_max_tooltip_size), INT_MAX)
      && RANGED_FIXNUMP (1, XCDR (Vx_max_tooltip_size), INT_MAX))
    {
      w->total_cols = XFIXNAT (XCAR (Vx_max_tooltip_size));
      w->total_lines = XFIXNAT (XCDR (Vx_max_tooltip_size));
    }
  else
    {
      w->total_cols = 80;
      w->total_lines = 40;
    }

  w->pixel_width = w->total_cols * FRAME_COLUMN_WIDTH (tip_f);
  w->pixel_height = w->total_lines * FRAME_LINE_HEIGHT (tip_f);
  FRAME_TOTAL_COLS (tip_f) = WINDOW_TOTAL_COLS (w);
  adjust_frame_glyphs (tip_f);

Or maybe I don't understand what you mean by "the size can be changed
by the window manager", please explain and show the code to which you
allude.

As for toolkits: we don't use this code when toolkit tooltips are
used.

> > No, because as I explained in my message, I don't think this should
> > be needed.  If the above assertion ever triggers, we will see what
> > kind of situation causes it, and can then discuss solutions.
> 
> How about simply asserting that try_window never returns 0?

That would trigger unnecessarily, creating false positives.  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.

Previous Next

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