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 07:57:07 +0300 Message-ID: <835y6kbgik.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> <877cr1nep6.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16590"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 64596@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 16 06:57:24 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 1qKtoy-00046Y-0u for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Jul 2023 06:57:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKtod-0000qy-TS; Sun, 16 Jul 2023 00:57:03 -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 1qKtoc-0000qW-Ju for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 00:57: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 1qKtoc-0002io-BI for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 00:57:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qKtoc-0002B8-7M for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 00:57: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 04:57: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.16894834138360 (code B ref 64596); Sun, 16 Jul 2023 04:57:02 +0000 Original-Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 04:56:53 +0000 Original-Received: from localhost ([127.0.0.1]:46367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKtoT-0002Al-5k for submit@debbugs.gnu.org; Sun, 16 Jul 2023 00:56:53 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59204) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKtoQ-0002AV-DM for 64596@debbugs.gnu.org; Sun, 16 Jul 2023 00:56:51 -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 1qKtoK-0002hZ-G3; Sun, 16 Jul 2023 00:56:44 -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=ekfPrg1oY1FuKkEbx+/lgsSTTYrtOT0y7B+F9XvCev4=; b=TgL0TtT6TDXq 2pnuuuMwoeG7kZemjyPtbS56iFFilSOHipagcOZkoppVnlzaXPoFJXAr2TQEqNEwsxN6nk8zdBkkN ao2qlc1fOsgWaKp/1RDkSb3dZ7WXVh7nZW3hMupxeKj1qOKsOFQv1yJTLNijhXMF4TY+OF6Gin0Pn XlblXsT32DoyrX6kvFMHcWejMmF4t4E4btL5Md0Fn1ZAkCVQactGqlKd7zLzU36EEcCSnJIFw2All 6C58bzcXZzyS7LKOrjEXZLmyDXDf1d9i7Be4QJZegSVNSAJ7QjtOmKAk12l2zqpViN8Kte8NxyvHT sHXA1FtE56dgAKvmx+LadA==; 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 1qKtoJ-0004SJ-No; Sun, 16 Jul 2023 00:56:44 -0400 In-Reply-To: <877cr1nep6.fsf@localhost> (message from Ihor Radchenko on Sat, 15 Jul 2023 19:43:17 +0000) 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:265262 Archived-At: > From: Ihor Radchenko > Cc: Stefan Monnier , 64596@debbugs.gnu.org > Date: Sat, 15 Jul 2023 19:43:17 +0000 > > Eli Zaretskii writes: > > > The actual issue with the above is different: it implies that > > update_mode_lines _always_ indicates that more than a single mode line > > should be updated (which is why we need to "consider all windows"). > > But is that actually true, i.e. does every place that assigns non-zero > > to update_mode_lines indeed perform a change which makes it > > _necessary_ to consider non-selected windows? > > At least, when the current buffer is only displayed in a single, > selected window, checking every window should not be necessary. The code which sets update_mode_lines doesn't know whether the current buffer will be displayed in a single window by the time redisplay kicks in. It doesn't even know whether it will still be the current buffer by that time. Because the Lisp program that is running and making the changes which cause update_mode_lines to be set can change these things before it finishes. These global variables come from the time when the Emacs redisplay was much less selective. It basically has only two modes: either redisplay only the selected window, or redisplay all the windows on all the frames. (Here "redisplay" means "examine for redisplay and decide whether and which parts need that", not necessarily "actually redraw".) When the various 'redisplay' flags were added, the intent was to make redisplay more selective, so that it could completely refrain from examining windows on a certain frame, for example. The right way to keep advancing in that direction is to extend these flags and maybe introduce more flags that will describe the need to redisplay in more detail. Global variables such as update_mode_lines can do that only if they provide specific values to describe each required aspect of redisplay. But in any case, the code which sets the variable cannot make decisions for redisplay, it can only describe the changes for redisplay to consider.