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#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) Date: Sun, 16 Jul 2023 17:27:41 +0300 Message-ID: <83r0p87wyq.fsf@gnu.org> References: <877cr4nez9.fsf@localhost> <83lefj4okb.fsf@gnu.org> <83fs5r3tqv.fsf@gnu.org> <834jm6fppc.fsf@gnu.org> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@gnu.org> <83a5vxejz6.fsf@gnu.org> <83r0p9b3om.fsf@gnu.org> <83jzv1b152.fsf@gnu.org> <83a5vxas9k.fsf@gnu.org> <871qh8o12z.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39933"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, 64596@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 16 16:28:15 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 1qL2jN-000AB8-Ui for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Jul 2023 16:28:13 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qL2jF-0002H9-9u; Sun, 16 Jul 2023 10:28:05 -0400 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 1qL2jC-0002Gj-Gb for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 10:28:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qL2jC-0006Hx-8j for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 10:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qL2jC-0005VF-4P for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 10:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Jul 2023 14:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64596 X-GNU-PR-Package: emacs Original-Received: via spool by 64596-submit@debbugs.gnu.org id=B64596.168951764921083 (code B ref 64596); Sun, 16 Jul 2023 14:28:02 +0000 Original-Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 14:27:29 +0000 Original-Received: from localhost ([127.0.0.1]:48371 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qL2if-0005Tz-8e for submit@debbugs.gnu.org; Sun, 16 Jul 2023 10:27:29 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50336) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qL2ia-0005Td-Hj for 64596@debbugs.gnu.org; Sun, 16 Jul 2023 10:27:28 -0400 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 1qL2iU-0006E7-Sg; Sun, 16 Jul 2023 10:27:18 -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=NEgPeovDXXlCv5BSlayFQ1HpF9a+wcJ4I3dkhK6iToA=; b=Ou9eg6snQWkh An4o84rsQAeRdLV6R64WzpA4udPgXirTcaELJqDGFWB1tVG/m8Xi1duXhwNpPfsqyoOi7Z22fH94n xlFHK/locBpiha2NFuNjkdVzwaVShfgil/SFASyt3sKeTIZb6lTIVrUNklO6tOVZ1Ktb+hRh8XDv0 Lio5Q4lrcQZq7aEZixo6Z8fien97LAaRMrL2OVYHGjgTTD/oePABmY9lKz3+JZS2IHOI4z9HrK3PM 8E3CZ782zG90cfzBcHXIBzotPuw9xEolami9GZ1Vq2LQiMe9LIHQugNRYqlHekxMb/ZtIaTxO4mC4 X/vlHMU08bA6V/GtI5UDJA==; 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 1qL2iU-0001ku-CR; Sun, 16 Jul 2023 10:27:18 -0400 In-Reply-To: (message from Stefan Monnier on Sun, 16 Jul 2023 10:04:30 -0400) 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:265343 Archived-At: > From: Stefan Monnier > Cc: Eli Zaretskii , 64596@debbugs.gnu.org > Date: Sun, 16 Jul 2023 10:04:30 -0400 > > >> - /* True means redisplay has to consider all windows on all > >> - frames. False, only selected_window is considered. */ > >> + /* False, means that only the selected_window needs to be updated. > >> + True means that other windows may need to be updated as well, > >> + so we need to consult the `redisplay` bits of > >> + all windows/buffer/frames. */ > >> bool consider_all_windows_p; > > > > BTW, is there any particular reason why windows_or_buffers_changed is > > not a queue of windows/buffer to be re-displayed? > > FWIW, I suspect that the loop over all windows is always > insignificant, so (in theory) we could get rid of the optimization that > looks only at the selected window in most cases and we wouldn't notice > any slowdown or measurable increase in CPU use. True, but with one caveat: the loop over all windows will not trivially return from redisplay_window if the window's frame has its redisplay flag set. So it is enough for the frame to have this flag set, for redisplay to have to consider all of its windows, even if the redisplay flag of each and every one of that frame's windows is reset. And once we decided not to return immediately after entering redisplay_window, the processing is not insignificant, since it involves making the window's buffer the current one, and as result setting all the values of buffer-local variables. So it sounds like we should make sure we don't set the frame's redisplay flag unless most or all of its windows actually need to be considered. Is this so with the current code? > So, replacing the `redisplay` bits with a queue is probably not a great > idea (especially since setting a bit is much faster than adding an > element to a queue where you need to try and avoid adding the same > element a hundred times). Agreed.