From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#56561: 29.0.50; Infloop in try_window Date: Sat, 16 Jul 2022 09:33:17 +0300 Message-ID: <83zgh9r2he.fsf@gnu.org> References: <874jzjwmhn.fsf@md5i.com> <83v8rzsdd1.fsf@gnu.org> <878rovxqjo.fsf@md5i.com> <83sfn2sy19.fsf@gnu.org> <83lesusl4w.fsf@gnu.org> <87lesumqgf.fsf@yahoo.com> <83ilnysbc5.fsf@gnu.org> <83fsj2s8fg.fsf@gnu.org> <83cze6s7xt.fsf@gnu.org> <83bktqs724.fsf@gnu.org> <878rotlpck.fsf@yahoo.com> <834jzhsj1a.fsf@gnu.org> <87v8rxk3eb.fsf@yahoo.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6884"; mail-complaints-to="usenet@ciao.gmane.io" Cc: mwd@md5i.com, 56561@debbugs.gnu.org To: Po Lu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 16 08:34:12 2022 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1oCbNS-0001Vw-W3 for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Jul 2022 08:34:11 +0200 Original-Received: from localhost ([::1]:33334 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oCbNR-00086F-1G for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 16 Jul 2022 02:34:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40250) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oCbNK-000866-Cf for bug-gnu-emacs@gnu.org; Sat, 16 Jul 2022 02:34:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:45025) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1oCbNK-0007yK-3q for bug-gnu-emacs@gnu.org; Sat, 16 Jul 2022 02:34:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1oCbNJ-0008LJ-RC for bug-gnu-emacs@gnu.org; Sat, 16 Jul 2022 02:34:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 16 Jul 2022 06:34:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 56561 X-GNU-PR-Package: emacs Original-Received: via spool by 56561-submit@debbugs.gnu.org id=B56561.165795321032031 (code B ref 56561); Sat, 16 Jul 2022 06:34:01 +0000 Original-Received: (at 56561) by debbugs.gnu.org; 16 Jul 2022 06:33:30 +0000 Original-Received: from localhost ([127.0.0.1]:42784 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCbMo-0008KY-B9 for submit@debbugs.gnu.org; Sat, 16 Jul 2022 02:33:30 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:55502) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1oCbMk-0008KJ-FN for 56561@debbugs.gnu.org; Sat, 16 Jul 2022 02:33:28 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52882) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oCbMf-0007vq-0Y; Sat, 16 Jul 2022 02:33:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=Z9xIKErB3y/VYSGsgDU4qBgmNifcK7WpCzgukHq6nvs=; b=CvMhsjGgeaqO aI+GxOiZDB7VF+m6fmjtZjyQv61MauWeaTZ5MNEHeLaL1aV/Bl9oMoEhQGhz0/YsPAFA3V7WyHNxz wjLXbs0Ey3a5cSy5YEN2Wcssj1rXF7QBsCTYe8xucXOWd0F/629/XhEtLtYhBnRSRq5QhTzYspqoq 20Bzfh3unZHs1WPiUeK4iCJoNAO4EzOucztmWYX6f+85/t+15URi4LcrRKee4A2TSfSLdbRQ6dk/R TxsvEWfWlAsb8YBLmgSwY24W2h/mj6yjaUH8voDpmby/AJuAoAuqABRKusun7fKL6cVYhdrj/vsHC mG28D0MKGP1t9TSXVnSZvw==; Original-Received: from [87.69.77.57] (port=3191 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oCbMe-0005sT-H6; Sat, 16 Jul 2022 02:33:20 -0400 In-Reply-To: <87v8rxk3eb.fsf@yahoo.com> (message from Po Lu on Sat, 16 Jul 2022 13:55:24 +0800) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:237143 Archived-At: > From: Po Lu > Cc: mwd@md5i.com, 56561@debbugs.gnu.org > Date: Sat, 16 Jul 2022 13:55:24 +0800 > > Eli Zaretskii 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.