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#61667: 29.0.60; Failure to redisplay Date: Tue, 21 Feb 2023 20:31:39 +0200 Message-ID: <83sfeyswdw.fsf@gnu.org> References: <04d7cb31-684c-07c0-ee7b-503514fc1a85@yandex.ru> <87a617eanz.fsf@yahoo.com> <4306cb76-a44c-3101-e43c-fd64afae4a51@yandex.ru> <871qmje2ws.fsf@yahoo.com> <83edqjtbss.fsf@gnu.org> <4e5e2a46-9b07-206a-6774-9f98f34cbd14@yandex.ru> <83y1orrolh.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5578"; mail-complaints-to="usenet@ciao.gmane.io" Cc: luangruo@yahoo.com, 61667@debbugs.gnu.org To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Feb 21 19:32:33 2023 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 1pUXRH-0001Av-Cy for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 21 Feb 2023 19:32:31 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pUXQr-0004T7-HI; Tue, 21 Feb 2023 13:32:05 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUXQo-0004SW-GM for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2023 13:32:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1pUXQo-0004on-81 for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2023 13:32:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1pUXQn-0001g3-MA for bug-gnu-emacs@gnu.org; Tue, 21 Feb 2023 13:32:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 21 Feb 2023 18:32:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 61667 X-GNU-PR-Package: emacs Original-Received: via spool by 61667-submit@debbugs.gnu.org id=B61667.16770042986415 (code B ref 61667); Tue, 21 Feb 2023 18:32:01 +0000 Original-Received: (at 61667) by debbugs.gnu.org; 21 Feb 2023 18:31:38 +0000 Original-Received: from localhost ([127.0.0.1]:57238 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUXQP-0001fO-EY for submit@debbugs.gnu.org; Tue, 21 Feb 2023 13:31:37 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:35638) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pUXQN-0001fB-Lw for 61667@debbugs.gnu.org; Tue, 21 Feb 2023 13:31:36 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pUXQI-0004cM-Dz; Tue, 21 Feb 2023 13:31:30 -0500 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=K4P111gM12g0zALbaut/l3whkXqx/NrK8d3JbLNGINU=; b=VQ+f8eprpNc/ 4/eXsH78bjbgYgNt/FI/LLCgd56Dc/X7jiC6IhvkBL0MLgBdFaEo9bLBc+DBTQq+VHcQDUMAKUte3 l4RXOOkl1eMyGFUDAfgZbLL/U9UknobNzkHGVS7SlBHqgNygU3pOQazNiqayQF1j3SQcdWzUOqt83 6T9VEy+toXqM1VYdyWs94n8m+ZFRmJmaQGrWJZx010RVzgIn9Yc+Hk/CWcCdAk+F/Zg/0yv8U//KH FuqLzTsIwRDeUHwLV0LfaP9YMCdkQfFoL4GuJ4xyXgQjn8AsNx1MFcRgD8w9yFq0L6ehsDMCNSEEi Xc8g9MQmedQ686wfULRr7A==; Original-Received: from [87.69.77.57] (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 1pUXQG-0004SR-Or; Tue, 21 Feb 2023 13:31:30 -0500 In-Reply-To: (message from Dmitry Gutov on Tue, 21 Feb 2023 19:25:28 +0200) 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-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:256307 Archived-At: > Date: Tue, 21 Feb 2023 19:25:28 +0200 > Cc: luangruo@yahoo.com, 61667@debbugs.gnu.org > From: Dmitry Gutov > > > I'm not surer I follow: why should a frame resize in this case? You > > just visit a file in an existing window of an existing frame, right? > > Or is the situation more complicated? If the latter, please tell the > > details, they could be relevant. > > Given how slow the unoptimized build is, I can usually start (and > finish) typing the command before Emacs has fully finished processing > the init script, including the default face customizations (which result > in frame resizing). > > >> So if I wait for it, and then use 'C-x b' (with Ido's support for > >> recentf), then I also can trigger the problem. > > > > Not following again: wait for what? And what happens when you use > > "C-x b"? > > 'C-x b' followed by the file name from history, followed by RET -> > visiting the previously visited file. From recentf. > > This behavior is driven by the option ido-virtual-buffers. Unlikely > affects something. > > But it allows me to shorten the scenario of visiting a file for the > first time after launching Emacs, so that I can trigger the bug faster > (over several tries). So you: . start Emacs . wait for the initial frame to be redrawn after the init files are processed . visit a file by typing "C-x b" and selecting a file from a list And then you see an empty window with the frame's title showing the file you selected. Is that correct? If so, what do you see on the mode line as the buffer name? > Overall, though, the unoptimized build makes it harder to reproduce: > I've only managed that 3 times, so far. Which likely means this is some kind of timing issue. Which perhaps also explains why trace-redisplay stops it from happening: it slows down redisplay because it needs to output the traces. So we are looking at some X or GTK event that comes in and somehow interrupts or prevents redisplay from doing its job, after it evidently started (because the frame title is updated at the beginning of a redisplay cycle)? Or maybe it's something that prevents us from swapping the double-buffering buffers so that the redrawn stuff is actually shown on the glass? > But the echo area is not getting redrawn either: the selection of > buffers to switch to is still visible as it was when I pressed RET. Just > the title bar changes. The echo area is updated together with the main > window showing the buffer. The echo area is shown in a window, so that seems to be part of not updating the windows on display.