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

Previous Next

Full log

View this message in rfc822 format

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: bug#56561: 29.0.50; Infloop in try_window
Date: Sun, 17 Jul 2022 08:43:03 +0300

> From: Po Lu <luangruo <at> yahoo.com>
> Cc: mwd <at> md5i.com,  56561 <at> debbugs.gnu.org
> Date: Sun, 17 Jul 2022 08:45:56 +0800
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> Yes.  The question was how to tell apart the situation where the rows
> >> don't extend to ZV because of that bug, and when they don't extend to ZV
> >> legitimately (since the tooltip is too small.)
> >
> > By "legitimately", you mean because of the restrictions in
> > x-max-tooltip-size?  I guess we should compare the values of
> > x-max-tooltip-size with their default values.
> 
> Indeed.  But the default is 80 by 40, so a restriction is still placed.
> So unfortunately that doesn't seem very helpful.

I don't see the problem.  If the default causes only partial display
(which would really need a HUGE tooltip), then whoever does that
without adjusting x-max-tooltip-size has only him/herself to blame,
and I see no problem.

We were talking about the conditions for an assertion.  Assertions are
for developers, they are compiled to nothing in a production build, so
such bad code in a production build will show a partial text.  While
in a development build, we will in such a case see an assertion, which
will tell us some code needs to be fixed.  Where's the problem?

Previous Next

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