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

Previous Next

Package: emacs;

Reported by: Michael Welsh Duggan <md5i <at> md5i.com>

Date: Thu, 14 Jul 2022 18:58:01 UTC

Severity: normal

Found in version 29.0.50

Full log


Message #95 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: 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?




This bug report was last modified 2 years and 331 days ago.

Previous Next


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