GNU logs - #64596, boring messages

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 13 Jul 2023 13:01:02 +0000
Resent-Message-ID: <handler.64596.B.168925325031066 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: 64596 <at> debbugs.gnu.org
From: Ihor Radchenko <yantar92@HIDDEN>
Date: Thu, 13 Jul 2023 13:00:26 +0000
Message-ID: <877cr4nez9.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
Received-SPF: pass client-ip=185.67.36.65; envelope-from=yantar92@HIDDEN;
 helo=mout01.posteo.de
X-Spam_score_int: -43
X-Spam_score: -4.4
X-Spam_bar: ----
X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1,
 DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1,
 RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=0.001, RCVD_IN_MSPIKE_WL=0.001,
 SPF_HELO_NONE=0.001, SPF_PASS=-0.001,
 T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no
X-Spam_action: no action
X-Spam-Score: -1.3 (-)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -2.3 (--)

Hello,

`force-mode-line-update' has the following FIXME:

  if (!NILP (all))
    {
      update_mode_lines = 10;
      /* FIXME: This can't be right.  */
      current_buffer->prevent_redisplay_optimizations_p = true;
    }
  else if (buffer_window_count (current_buffer))
    {
      bset_update_mode_line (current_buffer);
      current_buffer->prevent_redisplay_optimizations_p = true;
    }

This FIXME has been introduced in 655ab9a3800, shortly after
ecda65d4f7e, which moved this code from `set-buffer-modified-p'.

AFAIU, the purpose of disabling redisplay optimizations is avoiding the
situation when the modification flag is unset in the buffer, but the
buffer was actually modified, and has to be redrawn.

If my understanding is correct,
current_buffer->prevent_redisplay_optimizations_p = true does not belong
to `force-mode-line-update', but rather to `restore-buffer-modified-p'.

I also grepped through src/display.c looking at the usage of
update_mode_lines, and there seems to be no obvious situation where
update_mode_lines being non-nil is ignored.


In GNU Emacs 30.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
 3.24.38, cairo version 1.17.8) of 2023-07-06 built on localhost
Repository revision: d97b77e6c66db46b198c696f83458aa141794727
Repository branch: master
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Gentoo Linux


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent:

Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
X-Mailer: MIME-tools 5.505 (Entity 5.505)
Content-Type: text/plain; charset=utf-8
X-Loop: help-debbugs@HIDDEN
From: help-debbugs@HIDDEN (GNU bug Tracking System)
To: Ihor Radchenko <yantar92@HIDDEN>
Subject: bug#64596: Acknowledgement (30.0.50; On FIXME: in src/buffer.c:1481
 (force-mode-line-update))
Message-ID: <handler.64596.B.168925325031066.ack <at> debbugs.gnu.org>
References: <877cr4nez9.fsf@localhost>
X-Gnu-PR-Message: ack 64596
X-Gnu-PR-Package: emacs
Reply-To: 64596 <at> debbugs.gnu.org
Date: Thu, 13 Jul 2023 13:01:02 +0000

Thank you for filing a new bug report with debbugs.gnu.org.

This is an automatically generated reply to let you know your message
has been received.

Your message is being forwarded to the package maintainers and other
interested parties for their attention; they will reply in due course.

Your message has been sent to the package maintainer(s):
 bug-gnu-emacs@HIDDEN

If you wish to submit further information on this problem, please
send it to 64596 <at> debbugs.gnu.org.

Please do not send mail to help-debbugs@HIDDEN unless you wish
to report a problem with the Bug-tracking system.

--=20
64596: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D64596
GNU Bug Tracking System
Contact help-debbugs@HIDDEN with problems

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 13 Jul 2023 13:35:02 +0000
Resent-Message-ID: <handler.64596.B64596.16892552832786 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Ihor Radchenko <yantar92@HIDDEN>, Stefan Monnier <monnier@HIDDEN>
Cc: 64596 <at> debbugs.gnu.org
Date: Thu, 13 Jul 2023 16:34:44 +0300
Message-Id: <83v8eo3pfv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <877cr4nez9.fsf@localhost> (message from Ihor Radchenko on Thu,
 13 Jul 2023 13:00:26 +0000)
References: <877cr4nez9.fsf@localhost>
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

> From: Ihor Radchenko <yantar92@HIDDEN>
> Date: Thu, 13 Jul 2023 13:00:26 +0000
> 
> `force-mode-line-update' has the following FIXME:
> 
>   if (!NILP (all))
>     {
>       update_mode_lines = 10;
>       /* FIXME: This can't be right.  */
>       current_buffer->prevent_redisplay_optimizations_p = true;
>     }
>   else if (buffer_window_count (current_buffer))
>     {
>       bset_update_mode_line (current_buffer);
>       current_buffer->prevent_redisplay_optimizations_p = true;
>     }
> 
> This FIXME has been introduced in 655ab9a3800, shortly after
> ecda65d4f7e, which moved this code from `set-buffer-modified-p'.

Yes, it was part of Stefan's effort to make redisplay less expensive
by avoiding too thorough redisplay in as many use cases as possible.

> AFAIU, the purpose of disabling redisplay optimizations is avoiding the
> situation when the modification flag is unset in the buffer, but the
> buffer was actually modified, and has to be redrawn.

No, it's more subtle.  In a nutshell, it is meant to prevent redisplay
from applying certain optimizations (search xdisp.c for the uses of
this flag).  These optimizations are based on various assumptions,
such as that the current glyph matrix of the window is up-to-date.
Setting the prevent_redisplay_optimizations_p flag tells the display
engine that those assumptions are (or might be) false.

Updating the mode line usually requires more thorough redisplay,
especially when the only reason for that is that some Lisp called
force-mode-line-update -- without setting that flag, the display
engine could easily decide that the window doesn't need to be redrawn.

> If my understanding is correct,
> current_buffer->prevent_redisplay_optimizations_p = true does not belong
> to `force-mode-line-update', but rather to `restore-buffer-modified-p'.

The purpose of force-mode-line-update is to do what its name says,
regardless of whether the buffer was modified or not, and how it was
modified.  The idea is that Lisp programs which change something that
they know must affect the mode line call this function to make sure
the mode line is redrawn with up-to-date information.  By contrast,
buffer modifications could be such that don't affect redisplay at all,
or allow redisplay to use some shortcuts and redraw only a very small
portion of the window.

> I also grepped through src/display.c looking at the usage of
> update_mode_lines, and there seems to be no obvious situation where
> update_mode_lines being non-nil is ignored.

Stefan will tell, but I'm quite sure he wrote that FIXME because
removing that line caused regression in some situation.  I see that
this flag is tested without also testing update_mode_lines in
window-lines-pixel-dimensions, window-line-height, window-end,
redisplay_window, try_window_id, and display_line.  So I don't think I
agree with your conclusion.

Message sent to bug-gnu-emacs@HIDDEN:

Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 13 Jul 2023 17:20:02 +0000
Resent-Message-ID: <handler.64596.B64596.168926877625057 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <at> debbugs.gnu.org
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <83v8eo3pfv.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
Date: Thu, 13 Jul 2023 17:19:29 +0000
Message-ID: <87edlbd90e.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
Precedence: list
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>

Eli Zaretskii <eliz@HIDDEN> writes:

>> If my understanding is correct,
>> current_buffer->prevent_redisplay_optimizations_p = true does not belong
>> to `force-mode-line-update', but rather to `restore-buffer-modified-p'.
>
> The purpose of force-mode-line-update is to do what its name says,
> regardless of whether the buffer was modified or not, and how it was
> modified.  The idea is that Lisp programs which change something that
> they know must affect the mode line call this function to make sure
> the mode line is redrawn with up-to-date information.

I do not claim that I fully understand, but what is confusing is that a
number of other places in code simply use bset_update_mode_line without
disabling optimizations. In particular:

1. kill-all-local-variables
2. rename-buffer

Also, `force-window-update' disable optimizations for a given window,
but not when all windows should be updated - in contrast with the code
in OP.

So, `force-window-update' and `force-mode-line-update' are at least
inconsistent.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 13 Jul 2023 17:21:02 +0000
Resent-Message-ID: <handler.64596.B64596.168926883325165 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168926883325165
          (code B ref 64596); Thu, 13 Jul 2023 17:21:02 +0000
Received: (at 64596) by debbugs.gnu.org; 13 Jul 2023 17:20:33 +0000
Received: from localhost ([127.0.0.1]:40761 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qJzzU-0006Xp-Si
	for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 13:20:33 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:29042)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qJzzS-0006Xa-Bt
 for 64596 <at> debbugs.gnu.org; Thu, 13 Jul 2023 13:20:31 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 9983A1000C3;
 Thu, 13 Jul 2023 13:20:24 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 8813510009E;
 Thu, 13 Jul 2023 13:20:23 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689268823;
 bh=TB6qT68fXmFvxrFCCIIIAtLDR8zrnTs0URufBCoUZfY=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=MpW3VzjjFfviMpg7UWT+1nRVHfVNB8pO8pNdKC6yFUBeC3z07zzgVX/a2wr6BLx2G
 8OZROnZ1ignTVMDv2yh8ErXGc1PW0uATMQpywmL2kDrYjF3Sl6wpqWF+4NQGbY/XYG
 +2cRnlzszelO2TEo4+RApr4gfiW1GmdDaEyFMu3s05pZEFWYpN6MBBpnNnBaqMA7C0
 2kHpigZLKLuCwudBSI8b0moNQGfZDr1hvedxQsaitSpfGmOhjh9EVqdhhgv5YXBQfx
 T0gpogz3yu0egpBewaM5uC6mLvqPVo9CAxVNIMz2+ujgABKB+1b5HYXL8PNKeeo3Bk
 pBR96Q01t/rRw==
Received: from lechazo (lechon.iro.umontreal.ca [132.204.27.242])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 7A9091201E1;
 Thu, 13 Jul 2023 13:20:23 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <877cr4nez9.fsf@localhost> (Ihor Radchenko's message of "Thu, 13
 Jul 2023 13:00:26 +0000")
Message-ID: <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost>
Date: Thu, 13 Jul 2023 13:20:23 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.073 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> `force-mode-line-update' has the following FIXME:
>
>   if (!NILP (all))
>     {
>       update_mode_lines = 10;
>       /* FIXME: This can't be right.  */
>       current_buffer->prevent_redisplay_optimizations_p = true;
>     }
>   else if (buffer_window_count (current_buffer))
>     {
>       bset_update_mode_line (current_buffer);
>       current_buffer->prevent_redisplay_optimizations_p = true;
>     }
>
> This FIXME has been introduced in 655ab9a3800, shortly after
> ecda65d4f7e, which moved this code from `set-buffer-modified-p'.

ecda65d4f7e changed `force-mode-line-update` from

    (if all (with-current-buffer (other-buffer)))
    (set-buffer-modified-p (buffer-modified-p)))

to

    if (!NILP (all) || buffer_window_count (current_buffer))
      {
        update_mode_lines = 10;
        current_buffer->prevent_redisplay_optimizations_p = 1;
      }

That new code was (to the best of my knowledge) doing the same as what
the old ELisp code did (I got to that code basically by taking the sum
of the C code run by the original ELisp code and then simplifying it by
eliminating those things which canceled each other).

That code already had the same problem as the one I flagged with the
FIXME: when we do (force-mode-line-update t) the effect should be
global, so if `prevent_redisplay_optimizations_p` is needed in
`current_buffer` it should be needed in other displayed buffers as well.

> AFAIU, the purpose of disabling redisplay optimizations is avoiding the
> situation when the modification flag is unset in the buffer, but the
> buffer was actually modified, and has to be redrawn.
> If my understanding is correct,
> current_buffer->prevent_redisplay_optimizations_p = true does not belong
> to `force-mode-line-update', but rather to `restore-buffer-modified-p'.

I strongly suspect it doesn't belong in `force-mode-line-update`, indeed.

> Stefan will tell, but I'm quite sure he wrote that FIXME because
> removing that line caused regression in some situation.

Nope.  I put the FIXME simply because I realized that the code doesn't
make sense: if that line is sometimes necessary, then I'm pretty sure it's
not always sufficient.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 13 Jul 2023 19:04:02 +0000
Resent-Message-ID: <handler.64596.B64596.168927499113309 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168927499113309
          (code B ref 64596); Thu, 13 Jul 2023 19:04:02 +0000
Received: (at 64596) by debbugs.gnu.org; 13 Jul 2023 19:03:11 +0000
Received: from localhost ([127.0.0.1]:40873 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qK1ap-0003Sb-2p
	for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 15:03:11 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:40178)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qK1am-0003SN-7h
 for 64596 <at> debbugs.gnu.org; Thu, 13 Jul 2023 15:03:10 -0400
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 <eliz@HIDDEN>)
 id 1qK1ah-0000fX-1A; Thu, 13 Jul 2023 15:03:03 -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=meeLW4IXkmdzb/jqqtk3Ok+hqewuvzeUNWMJ1FvHDqY=; b=fFB20TUtgrLW
 r6SnJo048UxLmnG1wXdXGymiIIV90Y71gBopxHVQSi/HixwjsW01M+rA+g+h3/1SmNwWzmbLhM2aM
 Bzri20vTSVikDMwwI/e22RM/0C97phksNekkqBug+sY/V3YRZvPTo7h2A8kstIPgtt/5jKrGU+4s0
 llJ/Iuc2zMxBV7bryBpG7EQnTjj3bTlVhaW73X/eoEGvDMr7cJ7ZHF6zO8QKPAksOtPml5Hl1uOrm
 YSlSL1i4Hfg3em0oZdb+A/mRB4bKP0PRum2luJRKa5gXPzsWB4Il2xZjoQr09DlS2lIoMKJs21zg1
 SLFpNgRFbsMDz6F7Zu723g==;
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 <eliz@HIDDEN>)
 id 1qK1ag-0001nb-G2; Thu, 13 Jul 2023 15:03:02 -0400
Date: Thu, 13 Jul 2023 22:03:20 +0300
Message-Id: <83mszz4osn.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87edlbd90e.fsf@localhost> (message from Ihor Radchenko on Thu,
 13 Jul 2023 17:19:29 +0000)
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
 <87edlbd90e.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <at> debbugs.gnu.org
> Date: Thu, 13 Jul 2023 17:19:29 +0000
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> > The purpose of force-mode-line-update is to do what its name says,
> > regardless of whether the buffer was modified or not, and how it was
> > modified.  The idea is that Lisp programs which change something that
> > they know must affect the mode line call this function to make sure
> > the mode line is redrawn with up-to-date information.
> 
> I do not claim that I fully understand

Who does, when it comes to the display code?

> but what is confusing is that a number of other places in code
> simply use bset_update_mode_line without disabling optimizations. In
> particular:
> 
> 1. kill-all-local-variables
> 2. rename-buffer

bset_update_mode_line is for a single buffer, whereas the FIXME is for
the case where force-mode-line-update is called with a non-nil ALL
argument.

> Also, `force-window-update' disable optimizations for a given window,
> but not when all windows should be updated - in contrast with the code
> in OP.

When all the windows need to be updated, we force that via
windows_or_buffers_changed, which is a somewhat stronger flag, as far
as preventing optimizations goes.

> So, `force-window-update' and `force-mode-line-update' are at least
> inconsistent.

Why should they be entirely consistent?  They do different jobs.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 13 Jul 2023 19:09:01 +0000
Resent-Message-ID: <handler.64596.B64596.168927529513788 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168927529513788
          (code B ref 64596); Thu, 13 Jul 2023 19:09:01 +0000
Received: (at 64596) by debbugs.gnu.org; 13 Jul 2023 19:08:15 +0000
Received: from localhost ([127.0.0.1]:40890 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qK1fj-0003aK-1K
	for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 15:08:15 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:44544)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qK1fe-0003a4-Pw
 for 64596 <at> debbugs.gnu.org; Thu, 13 Jul 2023 15:08:14 -0400
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 <eliz@HIDDEN>)
 id 1qK1fZ-0004Dm-A2; Thu, 13 Jul 2023 15:08:05 -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=Tdd9U6CBT5HOFeFG1PALo4B5Pa+VNLVeNoWE0/oGWUE=; b=J2aEH88Q+T1a
 O6+HmYQ7ZxHNBJpNpD1BAmJMBHrmXtPkXi9FTb46gXiM6dddpb1IeUa/6PNWPiEnbzL1CDugQ+0jo
 mLZqqYZlIzP++KRnbmDFIkLrmeHVHJOsFAbT7v0TUK+2TagYNQ9V00sPw4A5F2OmLohz8AZLT7xOh
 +E8K6WtS6ukPlbZs2fqAgEnO4MthS50ErFU0/7Sd98B1kp/BC2pCh1+rMRsizes6z4SwgHtU7B2nc
 byBy9pubAF5nSv7LoKYLNL/LxSOTPjyQDhGhw6zjwNaGL7IauqmtqzLUFanASiauII7dMZNPdtu+G
 wfcDA0eeHbY7jMhajDfMhw==;
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 <eliz@HIDDEN>)
 id 1qK1fY-0002yZ-Q3; Thu, 13 Jul 2023 15:08:05 -0400
Date: Thu, 13 Jul 2023 22:08:20 +0300
Message-Id: <83lefj4okb.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvv8envj39.fsf-monnier+emacs@HIDDEN> (bug-gnu-emacs@HIDDEN)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: 64596 <at> debbugs.gnu.org
> Date: Thu, 13 Jul 2023 13:20:23 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@HIDDEN>
> 
> > AFAIU, the purpose of disabling redisplay optimizations is avoiding the
> > situation when the modification flag is unset in the buffer, but the
> > buffer was actually modified, and has to be redrawn.
> > If my understanding is correct,
> > current_buffer->prevent_redisplay_optimizations_p = true does not belong
> > to `force-mode-line-update', but rather to `restore-buffer-modified-p'.
> 
> I strongly suspect it doesn't belong in `force-mode-line-update`, indeed.

To the ALL branch or to both of them?

> > Stefan will tell, but I'm quite sure he wrote that FIXME because
> > removing that line caused regression in some situation.
> 
> Nope.  I put the FIXME simply because I realized that the code doesn't
> make sense: if that line is sometimes necessary, then I'm pretty sure it's
> not always sufficient.

Then I guess you or Ihor (or both) should try removing that line and
run with that for a while.

Alternatively, maybe in the case of ALL non-nil the code should set
the prevent_redisplay_optimizations_p flag of all the buffers that are
displayed in some window, since some redisplay optimizations are not
eligible when the mode-line is about to be updated.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 13 Jul 2023 21:01:02 +0000
Resent-Message-ID: <handler.64596.B64596.168928202524843 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168928202524843
          (code B ref 64596); Thu, 13 Jul 2023 21:01:02 +0000
Received: (at 64596) by debbugs.gnu.org; 13 Jul 2023 21:00:25 +0000
Received: from localhost ([127.0.0.1]:40920 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qK3QH-0006Sd-EL
	for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 17:00:25 -0400
Received: from mout02.posteo.de ([185.67.36.66]:48313)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qK3QC-0006SB-Vs
 for 64596 <at> debbugs.gnu.org; Thu, 13 Jul 2023 17:00:24 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id AE0C3240101
 for <64596 <at> debbugs.gnu.org>; Thu, 13 Jul 2023 23:00:14 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689282014; bh=/q4HZFegT/P0Kq5N56WR5k9Ogv08YvFvNW/2ptB1qRE=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=ZseDEfJaYYRp4foy33RrAbgT4xsI5a6Dw4CH8bGAhhXs9E/07R1XYtc3qZS33obLm
 tM4D///SWZiFjSBpVZ2K1ZD5+t1+E6ERMhEPYvQshnSyLysGY0M7kDBq3iWYsp/XEo
 CUQp17FS9wsXNUpf43GWr28Cuwm/gGpERUCEMWLZ85/jmh+a4NVBPROwcth8jnMaP3
 4N6M77m6rk5HijWL+v5XVoPq5VDe09k+tm8QVtEXEKxyHc6wELL3W1027bsDOwQTJG
 TgzXQM+twJ0Ieh4SStGQ0sfzz/bGSSvXSzVeiosSWL9IcpteZB/5qPefREQQShsA7W
 p+DjObJNjF+9A==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R26SY3v1yz9rxD;
 Thu, 13 Jul 2023 23:00:13 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <83lefj4okb.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
Date: Thu, 13 Jul 2023 21:00:18 +0000
Message-ID: <87zg3zcysd.fsf@localhost>
MIME-Version: 1.0
Content-Type: multipart/mixed; boundary="=-=-="
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

--=-=-=
Content-Type: text/plain

Eli Zaretskii <eliz@HIDDEN> writes:

> Then I guess you or Ihor (or both) should try removing that line and
> run with that for a while.

Yup. That's what I am already doing. See the attached diff.

Beware though that I still haven't looked closely into your and Stefan's
emails (it is late here) and I have no idea what I am doing in this
diff.


--=-=-=
Content-Type: text/x-patch
Content-Disposition: inline; filename=test.diff

diff --git a/src/buffer.c b/src/buffer.c
index 0c46b201586..db7dc5c3c68 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -1476,16 +1476,9 @@ DEFUN ("force-mode-line-update", Fforce_mode_line_update,
      (Lisp_Object all)
 {
   if (!NILP (all))
-    {
       update_mode_lines = 10;
-      /* FIXME: This can't be right.  */
-      current_buffer->prevent_redisplay_optimizations_p = true;
-    }
   else if (buffer_window_count (current_buffer))
-    {
       bset_update_mode_line (current_buffer);
-      current_buffer->prevent_redisplay_optimizations_p = true;
-    }
   return all;
 }
 
@@ -1502,6 +1495,8 @@ DEFUN ("set-buffer-modified-p", Fset_buffer_modified_p, Sset_buffer_modified_p,
 {
   Frestore_buffer_modified_p (flag);
 
+  if (!flag) current_buffer->prevent_redisplay_optimizations_p = true;
+
   /* Set update_mode_lines only if buffer is displayed in some window.
      Packages like jit-lock or lazy-lock preserve a buffer's modified
      state by recording/restoring the state around blocks of code.

--=-=-=
Content-Type: text/plain


-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

--=-=-=--

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Thu, 13 Jul 2023 22:03:01 +0000
Resent-Message-ID: <handler.64596.B64596.168928575732750 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168928575732750
          (code B ref 64596); Thu, 13 Jul 2023 22:03:01 +0000
Received: (at 64596) by debbugs.gnu.org; 13 Jul 2023 22:02:37 +0000
Received: from localhost ([127.0.0.1]:40967 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qK4OS-0008W9-Vb
	for submit <at> debbugs.gnu.org; Thu, 13 Jul 2023 18:02:37 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:51761)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qK4OP-0008Vo-OD
 for 64596 <at> debbugs.gnu.org; Thu, 13 Jul 2023 18:02:35 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7DA148060E;
 Thu, 13 Jul 2023 18:02:28 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 7504B801D6;
 Thu, 13 Jul 2023 18:02:27 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689285747;
 bh=WmgyprsdoNW5tR0EfnsiSE0S47OZKb6tfO2cGBjiF/w=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=V1Pn0qX38f+Jc6ABZz64InMhvgXl8zgjUxblqc7HctdHSTCk0oDyOjjp/pBtxmzsS
 876FaJ0OW5b7Ee1FTwW6Sgc9reFUX5QQuFJ8QwTKLYV5h8Ggap68Zdj2T2PQutBqMW
 dHTJr7CQqb1GJuQkyrxigrKjFZpq/x728bfUE5+QvCKj5kbNPqCeQWiL7qF6zlfKn7
 DvzagpUE0B4rKqSME0Thj9VxpuAEYmhT7lXeM4Y28Bo5G6p6q6tvmaB5xlIar0UJKW
 cnXM5khELAnQLLSB3v/hXt87N6foFwwwDB8tnKZ/3uRNSsR73GDCf6yms2H+RFA/1O
 ozbrTOWVfGh+Q==
Received: from pastel (unknown [104.247.239.133])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 490471201B8;
 Thu, 13 Jul 2023 18:02:27 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83lefj4okb.fsf@HIDDEN> (Eli Zaretskii's message of "Thu, 13 Jul
 2023 22:08:20 +0300")
Message-ID: <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN>
Date: Thu, 13 Jul 2023 18:02:26 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Then I guess you or Ihor (or both) should try removing that line and
> run with that for a while.

FWIW, I've been running without those two lines ever since I put this FIXME.

> Alternatively, maybe in the case of ALL non-nil the code should set
> the prevent_redisplay_optimizations_p flag of all the buffers that are
> displayed in some window, since some redisplay optimizations are not
> eligible when the mode-line is about to be updated.

Any reason why the corresponding optimizations don't consult the
`update_mode_lines` var (or the `update_mode_line` buffer flag), or
maybe have redisplay start by propagating the `update_mode_line` buffer
flag to `prevent_redisplay_optimizations_p`?


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 06:14:02 +0000
Resent-Message-ID: <handler.64596.B64596.16893152357558 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16893152357558
          (code B ref 64596); Fri, 14 Jul 2023 06:14:02 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 06:13:55 +0000
Received: from localhost ([127.0.0.1]:41363 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKC3v-0001xq-Ag
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 02:13:55 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:57142)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKC3r-0001xZ-8w
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 02:13:53 -0400
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 <eliz@HIDDEN>)
 id 1qKC3j-0006WN-Vq; Fri, 14 Jul 2023 02:13: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=c+oMUdm9A91ExEbeDMpOD4WKOzDUDbS/sK/EhsuQYy8=; b=OcJ9Qp8uW1TJ
 xFv7CQpaIXl6C5CjiJ/3rYov+a+yvL8xZbhlUxsaOZDth+SKEhF12VINUy0vbuZP4oNzRmcVtQeP+
 WVEg/TiC/sDpkv/WQTCd5dfsJWdAk0AcElEmN0JvGODqc00alBMSbw4QpwiQzXdHNl5liTaLx4dH7
 c4L5llmO0g7bC8jzAPZW9gwJxufXM+qI19kSv2pAf/ZEeSuoBQ6CkF5xgYwraf3PQOxZ5dQTsjWR5
 nvdXghLOkGu58Py9pjIoAV6QXDs4GoOEBVb/w8FZn9CRJz814mjiTZzFU3gUelaPK1ZA986BdEyOo
 VsqbHWvkZ0f7z4CBAp5N7w==;
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 <eliz@HIDDEN>)
 id 1qKC3h-00071A-Ff; Fri, 14 Jul 2023 02:13:41 -0400
Date: Fri, 14 Jul 2023 09:14:00 +0300
Message-Id: <83fs5r3tqv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Thu, 13 Jul 2023 18:02:26 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  64596 <at> debbugs.gnu.org
> Date: Thu, 13 Jul 2023 18:02:26 -0400
> 
> > Then I guess you or Ihor (or both) should try removing that line and
> > run with that for a while.
> 
> FWIW, I've been running without those two lines ever since I put this FIXME.

I'd be happier with the alternative I proposed, which you cite below.
Because bitter experience taught me that your, Stefan, usage patterns
evidently exclude some use cases, because bug reports pop up after
your similar changes where the display is not updated in some cases.
I'm sure the same is true for the usage patterns of anyone of us, so
doing this on a small number of systems is not enough.

> > Alternatively, maybe in the case of ALL non-nil the code should set
> > the prevent_redisplay_optimizations_p flag of all the buffers that are
> > displayed in some window, since some redisplay optimizations are not
> > eligible when the mode-line is about to be updated.
> 
> Any reason why the corresponding optimizations don't consult the
> `update_mode_lines` var (or the `update_mode_line` buffer flag), or
> maybe have redisplay start by propagating the `update_mode_line` buffer
> flag to `prevent_redisplay_optimizations_p`?

Once again, prevent_redisplay_optimizations_p is NOT (just) about
updating mode lines, it affects more optimizations.  There's also
windows_or_buffers_changed, which is even "stronger".  For example,
try_window_id checks the prevent_redisplay_optimizations_p flag and
punts if it is set, although that optimization method AFAIK has
nothing to do with redisplaying mode lines, it is only about updating
the text area.

It would be nice to analyze all those flags, make them more selective,
and understand/document better what optimizations and optional
processing are affected by each one of them.  It is a large and
somewhat ungrateful job, so if someone wants to do it by
systematically examining the situations where we set each one of those
flags and their effects on redisplay, I can offer my best help (though
I cannot afford doing this job myself).

Failing that, we could try disabling some portions of the code.  This
is not the best method of collecting such systematic information, IME,
certainly not if just a couple of people do that, because experience
teaches us that usage patterns differ wildly, and different
window-systems and different window managers sometimes have
significant effect on this stuff.  So if we want to use this
"phenomenological" approach, my suggestion is to allow disabling the
relevant parts of the display-related code at run time, controlled by
variables exposed to Lisp.  We already have a bunch of inhibit-*
variables that inhibit specific optimizations in xdisp.c; we could add
more.  Then we could set the defaults of these variables according to
our best understanding, and if and when redisplay problems are
reported, ask people to flip one or more of these inhibit-* variables
and see if the problems go away.

Again, this is not the best way, so if someone here is willing to do a
thorough job regarding this, I encourage him or her to take the first
way, although it is harder.  The advantage is that we will have a much
better understanding and documentation of these flags, and will
probably be able to improve the ad-hoc set of flags we have today and
make it easier to use and maintain.  (Ideally, these flags should be a
single bitmap with individual reasons representing the causes for
disabling optimizations, and each optimization should examine the bits
it cares about.)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 11:54:02 +0000
Resent-Message-ID: <handler.64596.B64596.168933558621744 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168933558621744
          (code B ref 64596); Fri, 14 Jul 2023 11:54:02 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 11:53:06 +0000
Received: from localhost ([127.0.0.1]:41557 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKHM9-0005ee-PK
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 07:53:06 -0400
Received: from mout01.posteo.de ([185.67.36.65]:60659)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qKHM6-0005e8-CL
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 07:53:04 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 5F715240027
 for <64596 <at> debbugs.gnu.org>; Fri, 14 Jul 2023 13:52:56 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689335576; bh=fuDynePCm5w31s51KG9yzpJqO01WXcZnoJG2SAt3Bno=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:
 Content-Transfer-Encoding:From;
 b=ImuoX09h/XGccc2YqVzqg9XP31Iv8CrZ0SuqjnxyGLQR92ZDyefBrZmyIprULhw9l
 j2zcpmA3lFfC/nzNCPvt+Wb2D7MmI/lvXykfgRd+zOXbKYjCfCXBs6fdjhhyzmRDN+
 lCxlBDAuYm6HngA4kZNW1MrW9kmZ8ZeGbFzxPpMsAjTB4tmazev6Ng99c7jcAYt5mk
 ltzOEKu6YvmPGXMb0BAgWYBh5tCN4ml6VqZxG8oczOVqcBG/7ryT+u8RvTqBey3zJo
 7Jej4T6JQUqiB2l3jVjZae2DT0noSPTJFW/HyLyFXHCJvY89kakaR8IiS1V5pFxsj5
 H5K9mV9kxLnYA==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R2VGb1G1pz9rxT;
 Fri, 14 Jul 2023 13:52:54 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <83v8eo3pfv.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
Date: Fri, 14 Jul 2023 11:53:02 +0000
Message-ID: <87bkgeiuap.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: quoted-printable
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

>> AFAIU, the purpose of disabling redisplay optimizations is avoiding the
>> situation when the modification flag is unset in the buffer, but the
>> buffer was actually modified, and has to be redrawn.
>
> No, it's more subtle.  In a nutshell, it is meant to prevent redisplay
> from applying certain optimizations (search xdisp.c for the uses of
> this flag).  These optimizations are based on various assumptions,
> such as that the current glyph matrix of the window is up-to-date.
> Setting the prevent_redisplay_optimizations_p flag tells the display
> engine that those assumptions are (or might be) false.

I'm afraid that the very existence of prevent_redisplay_optimizations_p
flag is a mistake hiding bugs with redisplay optimizations logic.

Currently, redisplay_internal has a number of conditions used to
determine if one or another optimization is safe to use + assertion that
!prevent_redisplay_optimizations_p.

When some code outside xdisp.c sets this flag, it is nothing but a
statement: "I was lazy enough to update xdisp.c properly, so I just
force bypassing optimizations".

> Updating the mode line usually requires more thorough redisplay,
> especially when the only reason for that is that some Lisp called
> force-mode-line-update -- without setting that flag, the display
> engine could easily decide that the window doesn't need to be redrawn.

I have explored xdisp a bit and AFAIU, once we are in redisplay_window,
mode line will be updated as long as update_mode_line is set (at least
to UPDATE_SOME), except when current window is MINI_WINDOW_P (this code
branch is not prevented by prevent_redisplay_optimizations_p though) or
when we give up redisplaying.

Calling redisplay_window may be prevented via needs_no_redisplay, unless
we have buffer->text->redisplay, which is set in bset_update_mode_line.
[ setting buffer->text->redisplay is rather awkward way to single mode
line update though ]

redisplay_window may also be postponed for frames that are not visible
or that are obscured, but it appears to be by design and not influenced
by prevent_redisplay_optimizations_p anyway =F0=9F=98=95

So, I see not why calling bset_update_mode_line is not sufficient to
force mode line update in all windows associated with a single buffer.

>> If my understanding is correct,
>> current_buffer->prevent_redisplay_optimizations_p =3D true does not belo=
ng
>> to `force-mode-line-update', but rather to `restore-buffer-modified-p'.
>
> The purpose of force-mode-line-update is to do what its name says,
> regardless of whether the buffer was modified or not, and how it was
> modified.  The idea is that Lisp programs which change something that
> they know must affect the mode line call this function to make sure
> the mode line is redrawn with up-to-date information.  By contrast,
> buffer modifications could be such that don't affect redisplay at all,
> or allow redisplay to use some shortcuts and redraw only a very small
> portion of the window.

Then, why do we need to call Fforce_mode_line_update in
set-buffer-modified-p? Wouldn't calling bset_redisplay be better?

--=20
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 12:26:01 +0000
Resent-Message-ID: <handler.64596.B64596.168933752825701 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168933752825701
          (code B ref 64596); Fri, 14 Jul 2023 12:26:01 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 12:25:28 +0000
Received: from localhost ([127.0.0.1]:41623 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKHrT-0006gT-FR
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 08:25:28 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:36854)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKHrQ-0006g4-Uz
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 08:25:26 -0400
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 <eliz@HIDDEN>)
 id 1qKHrJ-0005WW-EJ; Fri, 14 Jul 2023 08:25:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org;
 s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From:
 Date; bh=1MTcArGREzyBWFvkpegibOp7BSqNDL3JQ7boWS4BPFk=; b=sOOxCf8CfY/jmBBIx4Lb
 ktTaLGn9fh11ELQVGZEVw3ogvDBD8epkRvL4PDpMRELMhTEFPrrt7Muc/qt7mkgMPx9PFCTj88eC2
 0cf4UiihYM5P5qLDKRYYykncYfqAAiTogseI9qUosDU3tneh9xfMxS7FbkNBmC2CTy9414bXPn7wR
 5/vh37eSZHuCVII1UKqrApgwTqUEmuhp8G71oas52/OylcOCnM/gkIsiwMeIlNnVgi899Pzu4YUUG
 Qb2v+7i5mpqFLLGRZnrw2ljoK9mdrkWxhxggveTJlJ0paosTHLiAFGtjHwBRuwteTHP2sq6d5LroR
 wKTv1fbRWNkTKA==;
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 <eliz@HIDDEN>)
 id 1qKHr7-0002d8-RY; Fri, 14 Jul 2023 08:25:13 -0400
Date: Fri, 14 Jul 2023 15:25:24 +0300
Message-Id: <83fs5qfznv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87bkgeiuap.fsf@localhost> (message from Ihor Radchenko on Fri,
 14 Jul 2023 11:53:02 +0000)
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
 <87bkgeiuap.fsf@localhost>
MIME-version: 1.0
Content-type: text/plain; charset=utf-8
Content-Transfer-Encoding: 8bit
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <at> debbugs.gnu.org
> Date: Fri, 14 Jul 2023 11:53:02 +0000
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> > No, it's more subtle.  In a nutshell, it is meant to prevent redisplay
> > from applying certain optimizations (search xdisp.c for the uses of
> > this flag).  These optimizations are based on various assumptions,
> > such as that the current glyph matrix of the window is up-to-date.
> > Setting the prevent_redisplay_optimizations_p flag tells the display
> > engine that those assumptions are (or might be) false.
> 
> I'm afraid that the very existence of prevent_redisplay_optimizations_p
> flag is a mistake hiding bugs with redisplay optimizations logic.

I think you should avoid making such comments until you have a better
understanding of the redisplay logic, or else I will stop taking your
posts in this matter seriously.

> Currently, redisplay_internal has a number of conditions used to
> determine if one or another optimization is safe to use + assertion that
> !prevent_redisplay_optimizations_p.
> 
> When some code outside xdisp.c sets this flag, it is nothing but a
> statement: "I was lazy enough to update xdisp.c properly, so I just
> force bypassing optimizations".

No.  The optimization in question, which is disabled when
prevent_redisplay_optimizations_p flag is set for the current buffer,
is described in the comment before the condition:

  /* Optimize the case that only the line containing the cursor in the
     selected window has changed.

The prevent_redisplay_optimizations_p flag says, among other things,
that we are not in that case, and it is tested early enough in order
to prevent us from examining additional conditions which are just
waste of CPU cycles (and some of them are relatively expensive).

> > Updating the mode line usually requires more thorough redisplay,
> > especially when the only reason for that is that some Lisp called
> > force-mode-line-update -- without setting that flag, the display
> > engine could easily decide that the window doesn't need to be redrawn.
> 
> I have explored xdisp a bit and AFAIU, once we are in redisplay_window,
> mode line will be updated as long as update_mode_line is set (at least
> to UPDATE_SOME), except when current window is MINI_WINDOW_P (this code
> branch is not prevented by prevent_redisplay_optimizations_p though) or
> when we give up redisplaying.
> 
> Calling redisplay_window may be prevented via needs_no_redisplay, unless
> we have buffer->text->redisplay, which is set in bset_update_mode_line.
> [ setting buffer->text->redisplay is rather awkward way to single mode
> line update though ]
> 
> redisplay_window may also be postponed for frames that are not visible
> or that are obscured, but it appears to be by design and not influenced
> by prevent_redisplay_optimizations_p anyway 😕
> 
> So, I see not why calling bset_update_mode_line is not sufficient to
> force mode line update in all windows associated with a single buffer.

The mode line displays quite a lot of information.  It could also
display information we don't know about (on the level of the redisplay
code), because mode-line-format supports :eval, which can execute any
Lisp.  Therefore, there could be changes to the buffer that affect the
mode line indirectly.

One problem of this kind which we had relatively recently is when the
changes in mode-line-format or some of its :eval forms yields a mode
line that is significantly taller or smaller than the previously
displayed one.  Such changes in the mode-line height generally affect
the window(s) as well, not just the mode line itself.

Moreover, you will see in the wild that force-mode-line-update is used
not just to update the mode line, but also to force a more thorough
redisplay of one or more windows.

Thus, this is not as simple a problem as you seem to think, and we
need deeper analysis and more significant changes than simply deleting
the code that you didn't understand and think is redundant.  Please
keep in mind that people who wrote that code (and I don't mean myself)
were not stupid at all, and generally knew what they were doing!

> >> If my understanding is correct,
> >> current_buffer->prevent_redisplay_optimizations_p = true does not belong
> >> to `force-mode-line-update', but rather to `restore-buffer-modified-p'.
> >
> > The purpose of force-mode-line-update is to do what its name says,
> > regardless of whether the buffer was modified or not, and how it was
> > modified.  The idea is that Lisp programs which change something that
> > they know must affect the mode line call this function to make sure
> > the mode line is redrawn with up-to-date information.  By contrast,
> > buffer modifications could be such that don't affect redisplay at all,
> > or allow redisplay to use some shortcuts and redraw only a very small
> > portion of the window.
> 
> Then, why do we need to call Fforce_mode_line_update in
> set-buffer-modified-p? Wouldn't calling bset_redisplay be better?

You have read the large comment there which attempts to answer this
question, didn't you?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 13:49:01 +0000
Resent-Message-ID: <handler.64596.B64596.16893425275578 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16893425275578
          (code B ref 64596); Fri, 14 Jul 2023 13:49:01 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 13:48:47 +0000
Received: from localhost ([127.0.0.1]:41739 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKJA6-0001Ru-Dh
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 09:48:46 -0400
Received: from mout01.posteo.de ([185.67.36.65]:34397)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qKJA3-0001RZ-Sb
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 09:48:45 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 9BBAD240028
 for <64596 <at> debbugs.gnu.org>; Fri, 14 Jul 2023 15:48:37 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689342517; bh=/QXU+HukibJSAEYIWAQxNhcC6nF2Fz8F2IgMzE318t8=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=LbtfwjtjG9eItxgXTY1YycBi+V4OLXKpwv9dp0aFtDoHtA/k/rnG7jLula5Uxe5sU
 EJd9ZS78bD1SUxZM0OzF1iDht+x8XDoT2lI/ny/QwMysSFP2pcexsEGha475rx9NFh
 J82y6amIJkXkzwSpZhIvfXEDmGlPL8FkhQWgRxc3b2lvrbQtTAS9ULUgy7RGGJY9dt
 aeie8CIfm1dP2SP9YJize5yAT1R5ACKYKb05JAZEzG0EBcAAVai3/Dqu7tkcUIZ7jC
 c2qpWx5iLG8jeSje11hrgDMyj1POqdiY4VSqSLwz2pg0HkmAew0tu2tnKIwpe/ZjZ6
 5JfbI7nLmIwqg==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R2Xr43H5Cz6twZ;
 Fri, 14 Jul 2023 15:48:36 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <83fs5qfznv.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
 <87bkgeiuap.fsf@localhost> <83fs5qfznv.fsf@HIDDEN>
Date: Fri, 14 Jul 2023 13:48:43 +0000
Message-ID: <87351qioxw.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

>> I'm afraid that the very existence of prevent_redisplay_optimizations_p
>> flag is a mistake hiding bugs with redisplay optimizations logic.
>
> I think you should avoid making such comments until you have a better
> understanding of the redisplay logic, or else I will stop taking your
> posts in this matter seriously.

Your answer indicates that I missed something important after reading
the top comment in xdisp.c, redisplay_internal, redisplay_window, and
skimmed through a couple of other functions. But I still cannot figure
out what.

Note that I did not mean that previous committers had bad intentions. I
just think that the idea of having "disable all optimizations" flag is
causing the code quality that could be otherwise somewhat better (at
least, more explicit about why redisplay should take long path).

I think that replacing all the instances of setting this flag to more
explicit alternatives would improve the display performance and also
readability.

>> Currently, redisplay_internal has a number of conditions used to
>> determine if one or another optimization is safe to use + assertion that
>> !prevent_redisplay_optimizations_p.
>> 
>> When some code outside xdisp.c sets this flag, it is nothing but a
>> statement: "I was lazy enough to update xdisp.c properly, so I just
>> force bypassing optimizations".
>
> No.  The optimization in question, which is disabled when
> prevent_redisplay_optimizations_p flag is set for the current buffer,
> is described in the comment before the condition:
>
>   /* Optimize the case that only the line containing the cursor in the
>      selected window has changed.
>
> The prevent_redisplay_optimizations_p flag says, among other things,
> that we are not in that case, and it is tested early enough in order
> to prevent us from examining additional conditions which are just
> waste of CPU cycles (and some of them are relatively expensive).

Sure, but it is a very generic way to say this. It provides no detailed
reason what exactly changed in the buffer/window/frame that makes us
bypass this optimization.

Is it not always possible to use the other, more specific, existing
flags for redisplay to indicate that something important has been changed?

>> So, I see not why calling bset_update_mode_line is not sufficient to
>> force mode line update in all windows associated with a single buffer.
>
> The mode line displays quite a lot of information.  It could also
> display information we don't know about (on the level of the redisplay
> code), because mode-line-format supports :eval, which can execute any
> Lisp.  Therefore, there could be changes to the buffer that affect the
> mode line indirectly.

But isn't :eval processed by display_mode_lines? Once we take care to call
bset_update_mode_line, display_mode_lines is guaranteed to be executed,
AFAIU.

> One problem of this kind which we had relatively recently is when the
> changes in mode-line-format or some of its :eval forms yields a mode
> line that is significantly taller or smaller than the previously
> displayed one.  Such changes in the mode-line height generally affect
> the window(s) as well, not just the mode line itself.

Sure, and redisplay_window accounts for this when calling display_mode_lines:

      display_mode_lines (w);
      unbind_to (count1, Qnil);

      /* If mode line height has changed, arrange for a thorough
	 immediate redisplay using the correct mode line height.  */
      if (window_wants_mode_line (w)
	  && CURRENT_MODE_LINE_HEIGHT (w) != DESIRED_MODE_LINE_HEIGHT (w))
	{
	  f->fonts_changed = true;
	  w->mode_line_height = -1;
	  MATRIX_MODE_LINE_ROW (w->current_matrix)->height
	    = DESIRED_MODE_LINE_HEIGHT (w);
	}

> Moreover, you will see in the wild that force-mode-line-update is used
> not just to update the mode line, but also to force a more thorough
> redisplay of one or more windows.

Why not `force-window-update'? 

> Thus, this is not as simple a problem as you seem to think, and we
> need deeper analysis and more significant changes than simply deleting
> the code that you didn't understand and think is redundant.  Please
> keep in mind that people who wrote that code (and I don't mean myself)
> were not stupid at all, and generally knew what they were doing!

I understand, which is why I looked into git history and found that the
code in question is carried over during refactoring. Into a new function
with different meaning.

And I now looked deeper into the code, and see no obvious downsides of
removing current_buffer->prevent_redisplay_optimizations_p = true; from
force-mode-line-update specifically.
`set-buffer-modified-p' may need to be re-considered though as it is the
original place where setting prevent_redisplay_optimizations_p was done
(for different reasons).

>> > The purpose of force-mode-line-update is to do what its name says,
>> ... 
>> Then, why do we need to call Fforce_mode_line_update in
>> set-buffer-modified-p? Wouldn't calling bset_redisplay be better?
>
> You have read the large comment there which attempts to answer this
> question, didn't you?

Yup, I did. I thought bset_redisplay as an alternative, because it is
smarter than bset_update_mode_line when the buffer is displayed in
selected window (it is not necessary to assign DISPLAY_SOME flags).

However, I did miss the docstring that explicitly says that
`set-buffer-modified-p' forces mode line update. So, forcing mode line
update here is simply following the docstring and should not be
disputed.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 14:21:03 +0000
Resent-Message-ID: <handler.64596.B64596.168934443211340 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168934443211340
          (code B ref 64596); Fri, 14 Jul 2023 14:21:03 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 14:20:32 +0000
Received: from localhost ([127.0.0.1]:43136 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKJep-0002wq-A0
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:20:31 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:41400)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKJem-0002wU-Fb
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:20:29 -0400
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 <eliz@HIDDEN>)
 id 1qKJec-0003uV-Rb; Fri, 14 Jul 2023 10:20:20 -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=uKZp7mLtK9v/yC6q7BDLfNgrdR6wOAQkpDbEOKgOMec=; b=pPePg8hxrND0
 m3O5kUdyFP3qpgNWZLSE/pxqRwjR5A4TevevawcIbEuy8JAFtW0TdTDPzd9dCcEPMWAOU4dHOj6lA
 UPyirjRxWsjSkQPzZTu/ZHezVsQWP0bJ6WJpIwojEgBRuJeQTU56Fkon+J7vzvk4UUMvYYYPwNgnE
 zm8rbWDvNPEbAjDt7WGdt8Z3YJrZPm9jKk6Rr8MLhOl8ZRNehrMMmvF8QJiL8vG6kbjzWz2loluX8
 KWeiNESjMDJsO+jHhB7qCyiNt6Kz5XCejjFRRc8/XS4mbJllq24k2P52dwdW/wY2Ngq9RNqueflyK
 xYXgeJ6LTxtwgBBbuT+SUg==;
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 <eliz@HIDDEN>)
 id 1qKJeX-0001bG-BI; Fri, 14 Jul 2023 10:20:18 -0400
Date: Fri, 14 Jul 2023 17:20:30 +0300
Message-Id: <838rbifuc1.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87351qioxw.fsf@localhost> (message from Ihor Radchenko on Fri,
 14 Jul 2023 13:48:43 +0000)
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
 <87bkgeiuap.fsf@localhost> <83fs5qfznv.fsf@HIDDEN> <87351qioxw.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Fri, 14 Jul 2023 13:48:43 +0000
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> >> I'm afraid that the very existence of prevent_redisplay_optimizations_p
> >> flag is a mistake hiding bugs with redisplay optimizations logic.
> >
> > I think you should avoid making such comments until you have a better
> > understanding of the redisplay logic, or else I will stop taking your
> > posts in this matter seriously.
> 
> Your answer indicates that I missed something important after reading
> the top comment in xdisp.c, redisplay_internal, redisplay_window, and
> skimmed through a couple of other functions. But I still cannot figure
> out what.

Keep studying the code, is all I can suggest.  There's much more there
than meets the eye, IME.

> Note that I did not mean that previous committers had bad intentions. I
> just think that the idea of having "disable all optimizations" flag is
> causing the code quality that could be otherwise somewhat better (at
> least, more explicit about why redisplay should take long path).

I agree that the underlying logic is somewhat subtle, and sometimes
even mysterious, and I suggested a way to make this logic more
explicit and better documented.  But removing parts of display code
because we don't always understand it is a bad idea, IME, and usually
leads to bugs.  So it is a non-starter, as far as I'm concerned.

> I think that replacing all the instances of setting this flag to more
> explicit alternatives would improve the display performance and also
> readability.

It's possible.  But to consider such suggestions, I'd need to see a
detailed proposal backed up by serious analysis.  In any case, whether
it will make performance better is not yet clear; the original
motivation for this was not a performance issue at all.

> >   /* Optimize the case that only the line containing the cursor in the
> >      selected window has changed.
> >
> > The prevent_redisplay_optimizations_p flag says, among other things,
> > that we are not in that case, and it is tested early enough in order
> > to prevent us from examining additional conditions which are just
> > waste of CPU cycles (and some of them are relatively expensive).
> 
> Sure, but it is a very generic way to say this. It provides no detailed
> reason what exactly changed in the buffer/window/frame that makes us
> bypass this optimization.

What detailed reasons would you like to see?

> Is it not always possible to use the other, more specific, existing
> flags for redisplay to indicate that something important has been changed?

Which other flags?  And why do you think they are more specific?  At
least some of them are actually _less_ specific.

> >> So, I see not why calling bset_update_mode_line is not sufficient to
> >> force mode line update in all windows associated with a single buffer.
> >
> > The mode line displays quite a lot of information.  It could also
> > display information we don't know about (on the level of the redisplay
> > code), because mode-line-format supports :eval, which can execute any
> > Lisp.  Therefore, there could be changes to the buffer that affect the
> > mode line indirectly.
> 
> But isn't :eval processed by display_mode_lines? Once we take care to call
> bset_update_mode_line, display_mode_lines is guaranteed to be executed,
> AFAIU.

Executed, but with what data?  redisplay_window is a large function,
and employs quite a few of shortcuts.  If one of those shortcuts is
taken when it shouldn't be, the data shown on the mode line might be
inaccurate, because some of the variables affecting it were not
updated.

But let me turn the table and ask you: suppose that the
prevent_redisplay_optimizations_p flag is not needed for updating the
mode line per se -- what damage could it possibly do to redisplaying
the mode line? why are you so eager to remove that setting from
force-mode-line-update?

> > One problem of this kind which we had relatively recently is when the
> > changes in mode-line-format or some of its :eval forms yields a mode
> > line that is significantly taller or smaller than the previously
> > displayed one.  Such changes in the mode-line height generally affect
> > the window(s) as well, not just the mode line itself.
> 
> Sure, and redisplay_window accounts for this when calling display_mode_lines:
> 
>       display_mode_lines (w);
>       unbind_to (count1, Qnil);
> 
>       /* If mode line height has changed, arrange for a thorough
> 	 immediate redisplay using the correct mode line height.  */
>       if (window_wants_mode_line (w)
> 	  && CURRENT_MODE_LINE_HEIGHT (w) != DESIRED_MODE_LINE_HEIGHT (w))
> 	{
> 	  f->fonts_changed = true;
> 	  w->mode_line_height = -1;
> 	  MATRIX_MODE_LINE_ROW (w->current_matrix)->height
> 	    = DESIRED_MODE_LINE_HEIGHT (w);
> 	}

And if you've read the relevant bug reports, this doesn't always work.

But this is just an example, so even if you consider it to be solved,
it tells us that there can be other issues like that.  We are trying,
slowly, to go from general flags to more specific ones, but we are not
there yet, and removing code in this situation will just produce more
buggy redisplay.  I cannot agree to that.

> > Moreover, you will see in the wild that force-mode-line-update is used
> > not just to update the mode line, but also to force a more thorough
> > redisplay of one or more windows.
> 
> Why not `force-window-update'? 

Why does it matter? they both do almost the same (when the argument to
force-window-update is a window).

> And I now looked deeper into the code, and see no obvious downsides of
> removing current_buffer->prevent_redisplay_optimizations_p = true; from
> force-mode-line-update specifically.
> `set-buffer-modified-p' may need to be re-considered though as it is the
> original place where setting prevent_redisplay_optimizations_p was done
> (for different reasons).

Again, removing this is a non-starter, except if you want to do it
locally.  If we want to make any progress in this area in general, we
should take one of the two approaches I described in my previous
message.  Anything else is simply irresponsible, and won't happen on
my watch, sorry.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 14:21:03 +0000
Resent-Message-ID: <handler.64596.B64596.168934444211371 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168934444211371
          (code B ref 64596); Fri, 14 Jul 2023 14:21:03 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 14:20:42 +0000
Received: from localhost ([127.0.0.1]:43140 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKJez-0002xJ-Ui
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:20:42 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53340)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qKJey-0002x3-BY
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:20:40 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 197B0806BB;
 Fri, 14 Jul 2023 10:20:35 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id AE4478065C;
 Fri, 14 Jul 2023 10:20:33 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689344433;
 bh=g85h7DrYkFfZ4uXJWH3HQKmAp6VIcSbHe6uSrzTsZBg=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=LlxwI+f+e4xJpAPFwQVN7wjRbiqSin3YJ+GRmr3lXVasjkfkc6M6nw+wGmcGqCDfL
 XaW5KCcl7zi9V5eJfBNlbRWALD//dqd1xguiU6WHVnXhJuYkMeB8e7022rS3G/75Zc
 y6VPnVpODJ420Mquo6cLMhjbyWTGbiYUZmF+t+hlmqgd4QB2YC09s9xw3IXCQl6TAA
 88nljwSxbSNjnYgFJRzfY0/QxVuyJ1Of9n4zorYID6LFcM0mxq5EsbPDDCTwS0QeIs
 cMnkUppWXYddRW4TiohljCcUGkke9DS14o3Vy1K24T1+bnyuSrkDyID/B9mg3yCztf
 /8JudFu+BLonQ==
Received: from pastel (unknown [104.247.239.133])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 84DF9120330;
 Fri, 14 Jul 2023 10:20:33 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <87bkgeiuap.fsf@localhost> (Ihor Radchenko's message of "Fri, 14
 Jul 2023 11:53:02 +0000")
Message-ID: <jwvzg3yegxt.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
 <87bkgeiuap.fsf@localhost>
Date: Fri, 14 Jul 2023 10:20:32 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> I'm afraid that the very existence of prevent_redisplay_optimizations_p
> flag is a mistake hiding bugs with redisplay optimizations logic.

It's not that simple: the reliable way to do redisplay is to recompute
the whole glyph matrix anew for all windows every time any change occurs.
But that's unrealistic  Instead, we decouple the redisplay from the
buffer modifications.  In addition we try to keep track of which parts
may need to be redisplayed.  For that we use various auxiliary variables
which the code performing modifications can set to tell the redisplay
about which parts may need to be redisplayed.

Such variables include the `redisplay` and the `update_mode_line` bits,
buffer vars that keep track of a buffer-interval outside of which
there has not been any buffer changes, ...

`prevent_redisplay_optimizations_p` is just another of those vars.
The problem with that var is not its existence but the fact that by now
noone knows what it means, so we can't touch that code, basically :-(

> So, I see not why calling bset_update_mode_line is not sufficient to
> force mode line update in all windows associated with a single buffer.

I suspect the `prevent_redisplay_optimizations_p` is/was not meant to make
sure the modeline is updated, but to make sure some other part of the
window is/was also updated, but the code that decides whether to redraw
that other part never looked at `update_mode_line`.

E.g. maybe some code caused the mode-line or header-line to
appear/disappear and thus called `force-mode-line-update` for that
purpose, but the redisplay failed to notice that it needed to redraw
parts of the buffer text in response o that change, so the "quick fix"
was to set `prevent_redisplay_optimizations_p`?
[ This is a completely hypothetical scenario, I have no idea how this
  code came about.  ]

> Then, why do we need to call Fforce_mode_line_update in
> set-buffer-modified-p?

I don't know if it's still needed, or (if it is) whether it's the best
way to get the result nowadays, but I know why it's done: it's simply
because Fforce_mode_line_update used not to exist and instead the
standard way to force a mode-line update was to call
`set-buffer-modified-p` (yeah, I know it's weird, but that was simply
the cheapest operation exposed to ELisp that happened to set the needed
flags for the redisplay).  `force-mode-line-update` was introduced as
a cleaner API (but still implemented by calling
`set-buffer-modified-p`), so when I "straightened things out" by making
`force-mode-line-update` set the redisplay flags directly, I made
`set-buffer-modified-p` call `Fforce_mode_line_update` to be sure that
any old code out there calling `set-buffer-modified-p` to force a mode
line update would keep working as well as before.

> Wouldn't calling bset_redisplay be better?

Maybe (depends whether the redisplay code on its own checks stores the
old modified-p value to detect when it has changed), tho I doubt it
matters very much.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 14:32:02 +0000
Resent-Message-ID: <handler.64596.B64596.168934509312542 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168934509312542
          (code B ref 64596); Fri, 14 Jul 2023 14:32:02 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 14:31:33 +0000
Received: from localhost ([127.0.0.1]:43175 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKJpU-0003GD-Ra
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:31:33 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:64277)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qKJpS-0003G0-Ah
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:31:31 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 184491000C4;
 Fri, 14 Jul 2023 10:31:25 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id DD1B2100098;
 Fri, 14 Jul 2023 10:31:23 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689345083;
 bh=4y3KhmiSlbKzzDuAqX5qdAmyV4NDGbWJS1N7/uVAK3E=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=W1rMauvJNTsqAYODLOS3kMgkMjSW6AWWbUxjbXZImc2v3uiFuwpvIlsPcOL4ZnYuj
 BmjnVyYPVg2GgQmP+aZUjS/eI58b61N2b2WgIXWwZ7rWQUWn5VO54d76U1QRl0LHlp
 ewb88cakIrvTBI7FsmrNaChYIc/kHowdh/ZDl6DKb2gPPSLDoX5B90jh5imrt5DuyT
 ezTIW9pMk6hgF3J1hQia0rRdoyhNLRgN5XiV8RYJyw8i8QcxHIK35EIxuTkomrrhnq
 3l5gVQ05a7N8n+DICkc95CEHHMYiI9/BCcr7IBpFmx9rCdr78xdE8LwmPTQk4yXTuF
 LKyjr/YHMyEsQ==
Received: from pastel (unknown [104.247.239.133])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id B5CA3120264;
 Fri, 14 Jul 2023 10:31:23 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83fs5r3tqv.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 14 Jul
 2023 09:14:00 +0300")
Message-ID: <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN>
Date: Fri, 14 Jul 2023 10:31:23 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.113 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> > Then I guess you or Ihor (or both) should try removing that line and
>> > run with that for a while.
>> FWIW, I've been running without those two lines ever since I put this FIXME.
> I'd be happier with the alternative I proposed, which you cite below.

I assume you assumed that my lack of problems would make me think
removing those two lines is safe :-)

I'm fully aware that when it comes to redisplay, one or two testers are
definitely far from sufficient, don't worry.

>> > Alternatively, maybe in the case of ALL non-nil the code should set
>> > the prevent_redisplay_optimizations_p flag of all the buffers that are
>> > displayed in some window, since some redisplay optimizations are not
>> > eligible when the mode-line is about to be updated.
>> 
>> Any reason why the corresponding optimizations don't consult the
>> `update_mode_lines` var (or the `update_mode_line` buffer flag), or
>> maybe have redisplay start by propagating the `update_mode_line` buffer
>> flag to `prevent_redisplay_optimizations_p`?
>
> Once again, prevent_redisplay_optimizations_p is NOT (just) about
> updating mode lines, it affects more optimizations.  There's also

I know.  I didn't mean "consult `update_mode_lines` instead of
`prevent_redisplay_optimizations_p`" but "consult `update_mode_lines` in
addition to `prevent_redisplay_optimizations_p`".

> It would be nice to analyze all those flags, make them more selective,
> and understand/document better what optimizations and optional
> processing are affected by each one of them.  It is a large and
> somewhat ungrateful job, so if someone wants to do it by
> systematically examining the situations where we set each one of those
> flags and their effects on redisplay, I can offer my best help (though
> I cannot afford doing this job myself).

I can't see it happening ever in such a systematic way.
A more pragmatic approach is the one you propose afterwards: based on
our vague understanding of how things work, make a few simplifications,
expose them to our users and then see what bug reports we get in return.

I suspect a single boolean variable (which we could call
`internal--use-old-slow-redisplay`) to control those simplifications
would be enough.

We could set it to nil on `master` and to t in the release branch.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 14:51:02 +0000
Resent-Message-ID: <handler.64596.B64596.168934621614605 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Ihor Radchenko <yantar92@HIDDEN>, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168934621614605
          (code B ref 64596); Fri, 14 Jul 2023 14:51:02 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 14:50:16 +0000
Received: from localhost ([127.0.0.1]:43198 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKK7c-0003nU-Fg
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:50:16 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:28254)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qKK7b-0003nF-GS
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 10:50:15 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 3DD831000C4;
 Fri, 14 Jul 2023 10:50:10 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 1AD69100098;
 Fri, 14 Jul 2023 10:50:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689346209;
 bh=VUeavhYYGGc/VTdR1IhLf6LaWzqUBXSxXm3GpuOWW3E=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=PKQAGeLOmfjyZB+33zrcS/6VVf2AKNsR1AyLaNWMjKj9bkCutTAVOdFdjao4kuL5L
 nIP4X8a7onrZMIFeWgTS5LC7a9MrG11BMjK71aYmiUI6hiNjtinQbqckP5bHDmbMtY
 ftfUjMi9h8etLZEsoC3eo9HA6P+XiJ+K1ut70PtS0ubiXKnXhIqYJ3A61aOb4P1XU0
 60JDSA1JaAJve4itKVS+Dvu7DdT+tdDgykduX83BUF3YTyMHTiXJe6oBRnycGFzxyW
 qVS/SHQK8VFaJEPRhOEkHXgds3oFMId2TT0taG9m9AQOg8IFGEL7lKGm237wAHYjOj
 J9GMwTbShKjJw==
Received: from pastel (unknown [104.247.239.133])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id E63CC12033B;
 Fri, 14 Jul 2023 10:50:08 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83fs5qfznv.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 14 Jul
 2023 15:25:24 +0300")
Message-ID: <jwv4jm6eeg8.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
 <87bkgeiuap.fsf@localhost> <83fs5qfznv.fsf@HIDDEN>
Date: Fri, 14 Jul 2023 10:50:08 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.109 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Moreover, you will see in the wild that force-mode-line-update is used
> not just to update the mode line, but also to force a more thorough
> redisplay of one or more windows.

AFAIK these are bugs and we should not hide them by making
`force-mode-line-update` do more than what it's designed to do.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 15:56:02 +0000
Resent-Message-ID: <handler.64596.B64596.168935015820990 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168935015820990
          (code B ref 64596); Fri, 14 Jul 2023 15:56:02 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 15:55:58 +0000
Received: from localhost ([127.0.0.1]:43291 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKL9B-0005SU-Vq
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 11:55:58 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:59256)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKL9A-0005SH-9H
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 11:55:57 -0400
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 <eliz@HIDDEN>)
 id 1qKL93-0005VN-Dy; Fri, 14 Jul 2023 11:55:49 -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=BxcNCjnitzFicCyBWen11egZoW81M3KlUeLrIswUIyo=; b=I0w84sU7pBe8
 WCdZlFnaULIiwYJz2KuqTPBJtpEtPEh3dMHoX9IrtZU8cLddhpLBs5S03gr/iJObng+tP+XcQOd3Z
 s5kc1LZmDMVu8XAK5pwXfTwwdUnloomYhzrn0cnqBt+fdKe4AmlS68RpxsF7EpsMOwQBDOM3IdTh2
 1ZMKFJtLsBJG018sxh4MwPFd/LzK322UtGiGebJajygDT+ee0AyR7zdxmQ3zBvoGbvZtEf+CFg9zi
 q/zZXqqk1Xn+jk0c7sEu1FIccBQKZM6WVMegC/1f11gqQLsA7tGWwWla3734nn7kGoA17U9jypWP9
 MAXsDOGEShjwv7kUeQu+gg==;
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 <eliz@HIDDEN>)
 id 1qKL91-0007qx-G9; Fri, 14 Jul 2023 11:55:49 -0400
Date: Fri, 14 Jul 2023 18:56:06 +0300
Message-Id: <835y6mfpwp.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvzg3yegxt.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Fri, 14 Jul 2023 10:20:32 -0400)
References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@HIDDEN>
 <87bkgeiuap.fsf@localhost> <jwvzg3yegxt.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>,  64596 <at> debbugs.gnu.org
> Date: Fri, 14 Jul 2023 10:20:32 -0400
> 
> `prevent_redisplay_optimizations_p` is just another of those vars.
> The problem with that var is not its existence but the fact that by now
> noone knows what it means, so we can't touch that code, basically :-(

I think we can touch that code, but we need to do it carefully, and we
need to leave behind a "fire escape".

If you look at its uses (not where the flag is set, but where it is
checked), you will see that it either disables some optimization
(example: in try_window_id), or sets other variables, like
current_matrix_up_to_date_p.  In the first case, we need to go over
the places where the flag is set to true and think whether those
setters indeed need to disable each particular optimization.

In the second case, I think the flag is basically used to quickly
disable optimizations conditioned by those other variables, in a way
that prevents us to make more expensive tests.

If we understand better each of these cases -- and there aren't so
many of them -- we then could discuss whether to set the flag or not
and whether to replace it with something else, whether those are
other, more descriptive, flags or nothing.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 16:01:02 +0000
Resent-Message-ID: <handler.64596.B64596.168935042721482 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168935042721482
          (code B ref 64596); Fri, 14 Jul 2023 16:01:02 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 16:00:27 +0000
Received: from localhost ([127.0.0.1]:43296 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKLDW-0005aQ-Nu
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 12:00:27 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:52710)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKLDT-0005aA-S3
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 12:00:25 -0400
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 <eliz@HIDDEN>)
 id 1qKLDO-0000XW-Ga; Fri, 14 Jul 2023 12:00: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=YZ2LCmn7xu1N2+iuB5WH2JQ0tvVFiSExhqgtIzBiSG0=; b=O1GM2b5+2RYW
 DxgZ2Uw/PYV7Gre/G7eTbObueykUU3tBmdrYeVIVn29aXwXE7Ol5L7aow3yDHPYu1u8GBJ2VR5wBO
 CD99qN0elydXIwC7rN3IkQHZX/Odg4/dtoF5Xo00hFf5Zq0UByigDuHuhqRb8o/yGSCEANoECmyZE
 I/eyT1fTjbo/XNLeDhhYwEfWUFjowe2HkSe6hSgw1wjKMm/qmkvyAHq2zPMlKh5EjfvCCiT1zMtjq
 aurwnF4NjAiZeCahoqZbxQnh9sntoDpZGCnFE1RVlAseBFhTa0fSgzGAh1LJM/Mx+0zUS5QkkWzPV
 ZOQuqUIhZmI4+INtxkFqSA==;
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 <eliz@HIDDEN>)
 id 1qKLDI-0004uS-Gu; Fri, 14 Jul 2023 12:00:18 -0400
Date: Fri, 14 Jul 2023 19:00:31 +0300
Message-Id: <834jm6fppc.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Fri, 14 Jul 2023 10:31:23 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  64596 <at> debbugs.gnu.org
> Date: Fri, 14 Jul 2023 10:31:23 -0400
> 
> > It would be nice to analyze all those flags, make them more selective,
> > and understand/document better what optimizations and optional
> > processing are affected by each one of them.  It is a large and
> > somewhat ungrateful job, so if someone wants to do it by
> > systematically examining the situations where we set each one of those
> > flags and their effects on redisplay, I can offer my best help (though
> > I cannot afford doing this job myself).
> 
> I can't see it happening ever in such a systematic way.

I still hope it will.  It's a good way of getting familiar with the
display code, so maybe someone will step forward.

> A more pragmatic approach is the one you propose afterwards: based on
> our vague understanding of how things work, make a few simplifications,
> expose them to our users and then see what bug reports we get in return.
> 
> I suspect a single boolean variable (which we could call
> `internal--use-old-slow-redisplay`) to control those simplifications
> would be enough.

No, one variable is not enough -- it will never tell us which of the
potential flags or settings of the flag requires to be reinstated.  We
need to be able to investigate this at a finer granularity.

And the variables should be called something like
use-old-and-correct-redisplay-for-mode-line.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 17:39:02 +0000
Resent-Message-ID: <handler.64596.B64596.168935630332100 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168935630332100
          (code B ref 64596); Fri, 14 Jul 2023 17:39:02 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 17:38:23 +0000
Received: from localhost ([127.0.0.1]:43424 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKMkJ-0008Lg-HK
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 13:38:23 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:23390)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qKMkG-0008LR-6O
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 13:38:21 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 80D1E4409CA;
 Fri, 14 Jul 2023 13:38:14 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id EF34E44099C;
 Fri, 14 Jul 2023 13:38:12 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689356293;
 bh=riUq2GH3Uu3+Vf5xTCWI4Siwt65y78/lglZ1T7e79fE=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=BrxtqDo71oQm95e/JxQs2VEE+oSLdycSIXyOGr4w6rllS/lV/zGkiwy5Lz7HwNbW9
 T/UpWUfewxs7xDB1Oh2VeSwlvogESxhSvD7bmLVOy8T12Hb4D6SJWAfBnw+TxjWq4v
 xR/IFitRZZjjf8FKidbF1SvMdH8BtxW8RsGdl22AM6gmxC2fuuOS8SalDQR4aJU5hW
 m4ritejAWQYlbIDBEzp9mIjEOe/j4bwpAfI3HWpaNlBMBhMqn4w4XXX5veFfthvFVA
 n4dKO8TBd6CvskdWjWEy45J9ixZ7xtFxwvvVAjNyPjfb/NljtB0nRNX5B8RvjOQ69Z
 ltbuPhNeqUpnA==
Received: from pastel (unknown [104.247.239.133])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C30E1120397;
 Fri, 14 Jul 2023 13:38:12 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <834jm6fppc.fsf@HIDDEN> (Eli Zaretskii's message of "Fri, 14 Jul
 2023 19:00:31 +0300")
Message-ID: <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN>
Date: Fri, 14 Jul 2023 13:38:11 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.032 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> No, one variable is not enough -- it will never tell us which of the
> potential flags or settings of the flag requires to be reinstated.  We
> need to be able to investigate this at a finer granularity.

I doubt it.

What we need in order to investigate is a somewhat reproducible test
case and for that we need the bug to be exposed to as many users as
possible to increase the chance that one of them bumps into
a good recipe.

The variable is not used to investigate, but to make it ethical to
expose users to those potential bugs because they can set the var to
recover the old behavior as soon as they're tired of playing the
guinea pig.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 17:47:02 +0000
Resent-Message-ID: <handler.64596.B64596.1689356773337 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.1689356773337
          (code B ref 64596); Fri, 14 Jul 2023 17:47:02 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 17:46:13 +0000
Received: from localhost ([127.0.0.1]:43428 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKMrt-00005L-F1
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 13:46:13 -0400
Received: from mout01.posteo.de ([185.67.36.65]:57263)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qKMrr-000056-Ey
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 13:46:12 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 5442C240027
 for <64596 <at> debbugs.gnu.org>; Fri, 14 Jul 2023 19:46:05 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689356765; bh=VCbTpzeGwhcVNJ9JMvaaNLsh4gkmfJPZbcAcYQQiJnc=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=XRfMdGr2w8MqQ4Cop/juFA9AWuw02nKrNWfNFfVS+5VbEQWnBvSIPA6xR8eIF8fFW
 P4znTljfrpPm4K6VkrI5AWd5fE6zIQfPIbe3GKdfTt96DnLWDGptKlHywD0EmadFef
 Rr2UfJ+l5se3VQw+dQPpEls4Vs+tba0cThT5O2QHpo6M4+9e7eEsr9mqWJ1DE+UbpS
 XL/ZRLUy01sB4/XFZ//gpG3CBd1lHTVzMCxat7XC1NLudoRKz21rLk27v9dXH6r3rg
 CwdWgfpaZfQo8kzDp0bpDbslmTTghjq/TfY2tzvW2koWDxrVFNqzpQw6iERrahHzxQ
 mzJ8AyMPKj2tQ==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R2f645JTgz6tvh;
 Fri, 14 Jul 2023 19:46:04 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
Date: Fri, 14 Jul 2023 17:46:09 +0000
Message-ID: <87a5vyidy6.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Stefan Monnier <monnier@HIDDEN> writes:

> What we need in order to investigate is a somewhat reproducible test
> case and for that we need the bug to be exposed to as many users as
> possible to increase the chance that one of them bumps into
> a good recipe.
>
> The variable is not used to investigate, but to make it ethical to
> expose users to those potential bugs because they can set the var to
> recover the old behavior as soon as they're tired of playing the
> guinea pig.

+1.
Somewhat orthogonal, but related: if there are people who want to live
dangerously (even more dangerously than on master), it might be
interesting to have some kind of flip like "give me all the cutting edge
experimental features enabled, even if not backward-compatible".

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 19:05:02 +0000
Resent-Message-ID: <handler.64596.B64596.16893615018451 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16893615018451
          (code B ref 64596); Fri, 14 Jul 2023 19:05:02 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 19:05:01 +0000
Received: from localhost ([127.0.0.1]:43515 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKO68-0002CE-NW
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 15:05:01 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:32806)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKO67-0002C2-3r
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 15:05:00 -0400
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 <eliz@HIDDEN>)
 id 1qKO61-00035k-4H; Fri, 14 Jul 2023 15:04:53 -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=8Zszn1UGc6S+eTIEknOfybrH6Dht3bes5ejmd3ZuMtI=; b=VWtbUFQQBBMn
 il8esAbNmRGmU3jb0uvfeY4FfJiR3YYxSP+U3eM1snyoFPzFesF3QV14lhOClzZU6BvLbErobohnm
 kzf7sT30/ysEPU2NByNv7vIf9G4CzPDmxhha1FjhNbqC/K/xMo5wGM1Fg4Np5+yHEi9Dqd7fMZbKL
 Liqdc11FablySMcW0m73iYH3xOz5LRkJ1zRB3tAesZEuLYgCyoCnNeoYlxnU68pUt49Asso1g++Nj
 0/4pD+ZxzoMtbydN6kAUPbJIxIjqODlOjqWlupdMhJtuiWicl+TBzXsM/yo4Tc9ufmPgvU+g5U/Mw
 fEkZG9hIzGC8j41M1YER2w==;
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 <eliz@HIDDEN>)
 id 1qKO60-0006tv-KP; Fri, 14 Jul 2023 15:04:52 -0400
Date: Fri, 14 Jul 2023 22:05:11 +0300
Message-Id: <83ttu6e2l4.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Fri, 14 Jul 2023 13:38:11 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  64596 <at> debbugs.gnu.org
> Date: Fri, 14 Jul 2023 13:38:11 -0400
> 
> > No, one variable is not enough -- it will never tell us which of the
> > potential flags or settings of the flag requires to be reinstated.  We
> > need to be able to investigate this at a finer granularity.
> 
> I doubt it.
> 
> What we need in order to investigate is a somewhat reproducible test
> case and for that we need the bug to be exposed to as many users as
> possible to increase the chance that one of them bumps into
> a good recipe.
> 
> The variable is not used to investigate, but to make it ethical to
> expose users to those potential bugs because they can set the var to
> recover the old behavior as soon as they're tired of playing the
> guinea pig.

That's not what I had in mind when I proposed this approach.

What I had in mind was to investigate the need for every one of the
variables we use to disable redisplay optimizations in the various
cases: the prevent_redisplay_optimizations_p flag, the
update_mode_lines variable, the windows_or_buffers_changed variable,
etc. -- in the places in xdisp.c where these are heeded.  The purpose
was to understand better which ones should be used where and why.
This cannot be done with a single variable.

So if you want a single variable for some "ethical"
pseudo-investigation, I guess we deeply disagree here.  I'm not
interested in such "investigation".

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Fri, 14 Jul 2023 19:07:01 +0000
Resent-Message-ID: <handler.64596.B64596.16893615858611 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16893615858611
          (code B ref 64596); Fri, 14 Jul 2023 19:07:01 +0000
Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 19:06:25 +0000
Received: from localhost ([127.0.0.1]:43523 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKO7V-0002Ep-7b
	for submit <at> debbugs.gnu.org; Fri, 14 Jul 2023 15:06:25 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:58034)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKO7T-0002Ed-GV
 for 64596 <at> debbugs.gnu.org; Fri, 14 Jul 2023 15:06:24 -0400
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 <eliz@HIDDEN>)
 id 1qKO7O-0003ap-9e; Fri, 14 Jul 2023 15:06: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=Q2nRL3pB7XhtCnSnlmUXiIIDWWPdEJ0AY5jgz8ge2hw=; b=rE9FLPB1LVS6
 vB4dCNniAuzBlsbRmrTwBt8Ngl9ZePXoHFwGDkdgGfesvg6FoxSdt5R6miG7gA3y9L2uux6YNG0L1
 vSq5NOQMZDrEH10zm0Zy17WfO4k+vviSkeWTGBgqznw4C8YCWXqB1k/b2mNHg8VJRFFscH8tR3ayg
 CP6BeooB00pSmBKes68lotNXCjjp2YN+YlzHiUdcVkg4nQyBCS5xDKYAzikeqFh5iv9WQJuLlC4VN
 TWr7BV7Bm5o7WrVC+Zl3DLH24qOVZaKlYQRDlJ0SPMFzM6vYCEbb0TBuvRqkBGZAZ1I6lfIzKYnrX
 6DAyicX96Sxw/M//lVtpVg==;
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 <eliz@HIDDEN>)
 id 1qKO7N-00079Z-OP; Fri, 14 Jul 2023 15:06:18 -0400
Date: Fri, 14 Jul 2023 22:06:38 +0300
Message-Id: <83sf9qe2ip.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87a5vyidy6.fsf@localhost> (message from Ihor Radchenko on Fri,
 14 Jul 2023 17:46:09 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
> Date: Fri, 14 Jul 2023 17:46:09 +0000
> 
> Stefan Monnier <monnier@HIDDEN> writes:
> 
> > What we need in order to investigate is a somewhat reproducible test
> > case and for that we need the bug to be exposed to as many users as
> > possible to increase the chance that one of them bumps into
> > a good recipe.
> >
> > The variable is not used to investigate, but to make it ethical to
> > expose users to those potential bugs because they can set the var to
> > recover the old behavior as soon as they're tired of playing the
> > guinea pig.
> 
> +1.

 -1000

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 07:02:02 +0000
Resent-Message-ID: <handler.64596.B64596.1689404500457 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: yantar92@HIDDEN, monnier@HIDDEN
Cc: 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.1689404500457
          (code B ref 64596); Sat, 15 Jul 2023 07:02:02 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 07:01:40 +0000
Received: from localhost ([127.0.0.1]:43902 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKZHf-00007H-KU
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 03:01:40 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:59858)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKZHd-000070-T8
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 03:01:39 -0400
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 <eliz@HIDDEN>)
 id 1qKZHY-0005Ma-2r; Sat, 15 Jul 2023 03:01:32 -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=kdqPjZ+1/DZZZkkuLkaNGu1HrKfHWEc5DdRL2kAIxKU=; b=MaoifD/BJrA1
 OnKkzt3wo8/Skrwd2fogZOVyeHVmtnlGRBJv2wD5PAtHdeR2RPHkn5GRFecANdDf9OaNTAK/c2BTR
 n1Opj09ftvab95vk/qX51eYJAxfnjTbk/LHxxsPRxRTbgseQbr14kyuDtQ4kRQqrKoF9XzwQoC/Yo
 Q6QSXURHvEyjpTx3lw6fxMvN5UiJy/8jBIvDvKBr47Hc9c5vVFbSfjSkas9mM8Gc/nBFCp7wU7yoS
 DxkYokmauUn2TWSL1Zbm6JPZUbFpgcXHHy7kgvqKlB5wt8AOWldv2OKn70MefE5I8RJUJlHK2yt1g
 1UaajZDdcLWeMUo+rjqTEQ==;
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 <eliz@HIDDEN>)
 id 1qKZHV-00031E-3q; Sat, 15 Jul 2023 03:01:31 -0400
Date: Sat, 15 Jul 2023 10:01:49 +0300
Message-Id: <83a5vxejz6.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <83sf9qe2ip.fsf@HIDDEN> (message from Eli Zaretskii on Fri, 14
 Jul 2023 22:06:38 +0300)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Fri, 14 Jul 2023 22:06:38 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> 
> > From: Ihor Radchenko <yantar92@HIDDEN>
> > Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
> > Date: Fri, 14 Jul 2023 17:46:09 +0000
> > 
> > Stefan Monnier <monnier@HIDDEN> writes:
> > 
> > > What we need in order to investigate is a somewhat reproducible test
> > > case and for that we need the bug to be exposed to as many users as
> > > possible to increase the chance that one of them bumps into
> > > a good recipe.
> > >
> > > The variable is not used to investigate, but to make it ethical to
> > > expose users to those potential bugs because they can set the var to
> > > recover the old behavior as soon as they're tired of playing the
> > > guinea pig.
> > 
> > +1.
> 
>  -1000

Let me explain once again my position on this.

We currently have quite a few flags that are used by various Emacs
commands to give redisplay hints about what should be done:

  . redisplay flag of a buffer
  . redisplay flag of a window
  . redisplay flag of a frame
  . prevent_redisplay_optimizations_p flag of a buffer
  . clip_changed flag of a buffer
  . update_mode_line flag of a window
  . must_be_updated_p flag of a window
  . cursor_type_changed flag of a frame
  . face_change flag of a frame
  . update_mode_lines variable
  . windows_or_buffers_changed variable

(There are a few more, but these are the bulk.)  The 3 redisplay flags
at the beginning of this list did not exist before Emacs 24, they were
added in the hope to make the flags more selective and
self-explanatory.  But just knowing, for example, that a buffer's text
was changed says almost nothing about which optimizations can and
cannot be used, whether or not the mode line needs to be updated, nor
even if the window(s) showing the buffer need to be redrawn (since the
change could be in a portion of the buffer that is not visible in any
of the windows).

Anyway, we now have this dozen of flags and variables, and one of them
is prevent_redisplay_optimizations_p.  It makes absolutely no sense to
me to try to "solve" the "problem" of this single flag in the single
case that started this thread.  Even if this flag should not be set in
the particular place with a FIXME -- which was not convincingly
demonstrated here -- so what? what harm can that possibly make in this
specific case?  None.  What we have now might look untidy at best, but
it does work, and works well.  It took an effort to get here, but the
current situation has been stable for several years: I don't remember
any significant redisplay problems reported for the last several
years.

What we do need is to make some better order out of these flags,
understand better what does each one of them tell the display engine,
and perhaps make some of them more selective.  And we need to document
these understandings.

So this is the deal: if someone wants to try to do this job, or even
some part of it, you will have my full support, my attention, and any
form of help I can practically provide.  But I will not agree to
random poking at this or that particular flag, unless there's
convincing evidence that it causes a display bug or a significant
performance problem.  Because otherwise making changes in code that we
don't sufficiently understand can only cause bugs, and guess who gets
to work on fixing them.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 07:23:01 +0000
Resent-Message-ID: <handler.64596.B64596.16894057802593 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16894057802593
          (code B ref 64596); Sat, 15 Jul 2023 07:23:01 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 07:23:00 +0000
Received: from localhost ([127.0.0.1]:43938 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKZcK-0000fl-9D
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 03:23:00 -0400
Received: from mout01.posteo.de ([185.67.36.65]:35953)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qKZcI-0000fS-4a
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 03:22:58 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id E9D07240027
 for <64596 <at> debbugs.gnu.org>; Sat, 15 Jul 2023 09:22:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689405771; bh=IjXCJws5tPF33EQGK0qNA1vFF9/aFA/r+PI9s9GdU4U=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=gzSeQquoEwyDUov//sQ01fwAA7b+VqaX0VZ74e3Cu6+Ghljmoy7KAdU53Bfg3JpeH
 AqgxXuezjQh6e4k897WxqwOECsHLuRDTtt7pELgHOfQBXosLlGeHVKSZSaulJJIkFv
 JMbxXWhFVQ72nj4ex5Ne77Q+BsJHXHub1mtg+cq3oM0e6/y2H19+VEx3bBZDCbiMkI
 AGUdRMolFT8LagsNfz7C/azNctbqrtWuRIWJVSatL2gDesYBlWxF/I9SDOhiL7eDfy
 nEvxPCzXuHG9amJcYLTFaN20A2L2PjROE8BvAjuRcjg6z4I2fpGfcRuQIkQ8vuAkOI
 C+P4LIVkr1DFA==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R30DV61Qsz9rxP;
 Sat, 15 Jul 2023 09:22:50 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <83a5vxejz6.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
Date: Sat, 15 Jul 2023 07:22:59 +0000
Message-ID: <87lefhhc4s.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

> What we do need is to make some better order out of these flags,
> understand better what does each one of them tell the display engine,
> and perhaps make some of them more selective.  And we need to document
> these understandings.

I agree.
From my recent reading of the commentary in xdisp.c, one apparently
missing summary is which window and frame components are considered by
the redisplay code.

"Glyph rows." section in the top comment talk about margins + text area,
but the real redisplay_internal appears to consider (1) title bars; (2)
menu bars; (3) header line; (4) tab line; (5) mode-line; (6) window
text; (7) echo area (which is treated specially).

> ....  But I will not agree to
> random poking at this or that particular flag, unless there's
> convincing evidence that it causes a display bug or a significant
> performance problem.  Because otherwise making changes in code that we
> don't sufficiently understand can only cause bugs, and guess who gets
> to work on fixing them.

That's understandable.
But the general idea of having some kind of "experimental" flag might be
still useful in other situations. Not necessarily redisplay.
Of course, such experiments should be still weighed carefully.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 08:53:02 +0000
Resent-Message-ID: <handler.64596.B64596.168941114712734 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168941114712734
          (code B ref 64596); Sat, 15 Jul 2023 08:53:02 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 08:52:27 +0000
Received: from localhost ([127.0.0.1]:44118 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKb0s-0003JK-R0
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 04:52:27 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:60104)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKb0r-0003J8-9P
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 04:52:26 -0400
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 <eliz@HIDDEN>)
 id 1qKb0l-00063M-PZ; Sat, 15 Jul 2023 04:52:19 -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=ToaqyB4WbnjzQ7pDIC0oWbkTQu2mh6Zy30tPd61pw7g=; b=eiiEF7unh2Bq
 rprU7iV+Tzb3rBzQMZ5LqmTq78QaGZIcRSo4/PF9YYem9KTMk2zsKnj6GqpGlZi6nmQgvXYWDvxIN
 C427yeXCjj215h9HI3DUrpxcKhtrQ4RJ0wJ002Mv2S68QzytWdH5825sf11p1kgqXlcZWudYSz1cX
 PmVIQHCLvZmJHtKu9uojQCEV4QEUt5R6BYyyJf5PO6AaTk1cEyy5MIqi71zpxzEUousJP3YhTU/zD
 qou6Qn/ylqrzjymyftLdNgJgRRUunDZSBz1Hf2PRZJm9ixMvkmVKLcRfEMUX2h4qf768jbL+u2AA3
 RoOim8FLtmGA3O/5/hWR/g==;
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 <eliz@HIDDEN>)
 id 1qKb0l-0008Ik-7Q; Sat, 15 Jul 2023 04:52:19 -0400
Date: Sat, 15 Jul 2023 11:52:41 +0300
Message-Id: <83ilald09y.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87lefhhc4s.fsf@localhost> (message from Ihor Radchenko on Sat,
 15 Jul 2023 07:22:59 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN> <87lefhhc4s.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Sat, 15 Jul 2023 07:22:59 +0000
> 
> >From my recent reading of the commentary in xdisp.c, one apparently
> missing summary is which window and frame components are considered by
> the redisplay code.

Basically, all of them, I'd say.

> "Glyph rows." section in the top comment talk about margins + text area,
> but the real redisplay_internal appears to consider (1) title bars; (2)
> menu bars; (3) header line; (4) tab line; (5) mode-line; (6) window
> text; (7) echo area (which is treated specially).

That section indeed mentions the text area and the margins, but only
because the glyph rows distinguish between them.  The other areas you
mention either don't use our glyphs (title bar), or have no margin
areas (mode line, header line, menu bar, etc.), only the text area.

Echo area is displayed in a mini-window, which is just a window,
albeit a special one.

> > ....  But I will not agree to
> > random poking at this or that particular flag, unless there's
> > convincing evidence that it causes a display bug or a significant
> > performance problem.  Because otherwise making changes in code that we
> > don't sufficiently understand can only cause bugs, and guess who gets
> > to work on fixing them.
> 
> That's understandable.
> But the general idea of having some kind of "experimental" flag might be
> still useful in other situations. Not necessarily redisplay.
> Of course, such experiments should be still weighed carefully.

I'm okay with such experimental flags, and we did use them in the past
(still have some of them in the current sources).  I'm just saying
those should be selective enough to allow enabling/disabling a small
set of features, not all of them together.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 14:50:02 +0000
Resent-Message-ID: <handler.64596.B64596.168943258731254 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168943258731254
          (code B ref 64596); Sat, 15 Jul 2023 14:50:02 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 14:49:47 +0000
Received: from localhost ([127.0.0.1]:45744 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKgag-000882-Vu
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 10:49:47 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21472)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qKgae-00087p-Kn
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 10:49:46 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 559BA80712;
 Sat, 15 Jul 2023 10:49:39 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D0C84805DE;
 Sat, 15 Jul 2023 10:49:37 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689432577;
 bh=DQFTOhqrUTJIgUo9roA7Rz5Sw2Qi/pdTMI3IEm89Yfw=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=QzKzXa34F3HaXwjdB6pZEzhuHE51NbZhrnnokDqx50QFwv8k/qa7mlnHmo7UBft/g
 XWCsWeh0iDlVBoR8UepvxQMM5O9ceyNN2mEnqiU7W+405wisifypVPb8S4TXKDSVI7
 v98VFwh4vQJRYWgC4HK5d0kJ7rTG5uEv5OJc63jBjRS1kSTpsFPhfyNaeXTsMLkCTA
 HsLBRYjTU8Ch/9J7vMikMQ2dW4t3qWwcJsma2kK/IVZVrTbgz4qJit9RBzcHOvAqmr
 ja9qtS174hmorR7P2mXDwQ2I2rMlt24WQgFgdKkJnWnv/K/e/VNevNy/ggbU/R3K8T
 Ht+QJ8QAaJf6Q==
Received: from pastel (unknown [108.175.230.17])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A20451203A1;
 Sat, 15 Jul 2023 10:49:37 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83a5vxejz6.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 15 Jul
 2023 10:01:49 +0300")
Message-ID: <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN>
Date: Sat, 15 Jul 2023 10:49:37 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.250 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> We currently have quite a few flags that are used by various Emacs
> commands to give redisplay hints about what should be done:
>
>   . redisplay flag of a buffer
>   . redisplay flag of a window
>   . redisplay flag of a frame
>   . update_mode_line flag of a window
>   . update_mode_lines variable
>   . windows_or_buffers_changed variable

I can explain what these are supposed to represent (IOW, if there's
a bug linked to them, I should be able to tell you whether the blame
goes to the redisplay code (which "reads" these vars) or in the
non-redisplay code (which sets these vars)).

If you read their docs and have questions, I'd love to hear them so
I can improve their doc.

>   . clip_changed flag of a buffer
    . beg_unchanged of a buffer_text
    . end_unchanged of a buffer_text

I think their intended meaning is fairly clear.  I haven't really
played with the corresponding part of the code, so I don't know if the
code really matches my expectations, but I have the impression that
there shouldn't be too many surprises.

>   . cursor_type_changed flag of a frame
>   . face_change flag of a frame

I can see what these are supposed to mean as well, but I'm less sure
that that intended meaning really matches the code (e.g., I wouldn't be
surprised to discover that one of them is also (ab)used for something
else).

>   . prevent_redisplay_optimizations_p flag of a buffer
>   . must_be_updated_p flag of a window

No idea what these mean.
The name `must_be_updated_p` makes it sound to me like it's redundant
with the `redisplay` flag above.

> (There are a few more, but these are the bulk.)  The 3 redisplay flags
> at the beginning of this list did not exist before Emacs 24, they were
> added in the hope to make the flags more selective and
> self-explanatory.

They were added exclusively to refine:

    . update_mode_lines variable
    . windows_or_buffers_changed variable

since these have a global meaning whereas in most cases only a small
number of the windows should be affected.

[ IOW, the refinement targeted use cases where there are many windows.
  I often have a hundred windows or more :-)  ]

> performance problem.  Because otherwise making changes in code that we
> don't sufficiently understand can only cause bugs,

It can introduce bugs, but in my experience when dealing with code
I don't understand, it's by breaking the code that you learn how it
works, so saying "can only cause bugs" doesn't make sense.  The change
can bring more clarity to the code, which is beneficial in the long
term, and if it introduces bugs then presumably some users will see
them, report them, and that will bring us better understanding of
the code.

That's eactly what happened when I introduced the 3 `redisplay` bits
above: it did introduce a few bugs, but overall it made the code
more clear.  My experience has been very positive there, and I hope you
wouldn't veto a similar change in the future.

> and guess who gets to work on fixing them.

AFAIK, for the bugs introduced by those `redisplay` bit: I did, as
it should.  And it wasn't terribly hard (largely because I indeed knew
(because I had decided it myself) what meant what and hence where
a problem should be fixed).


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 15:22:02 +0000
Resent-Message-ID: <handler.64596.B64596.168943451311644 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168943451311644
          (code B ref 64596); Sat, 15 Jul 2023 15:22:02 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 15:21:53 +0000
Received: from localhost ([127.0.0.1]:45801 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKh5k-00031j-Mt
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 11:21:53 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:36178)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKh5i-00031R-93
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 11:21:51 -0400
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 <eliz@HIDDEN>)
 id 1qKh5c-0006cX-Qz; Sat, 15 Jul 2023 11:21: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=QnwMd0qkxoJvoRkTqojipFtMP4L+QswPY5E96mA2aRk=; b=gaHV253vggVZ
 qMDS+MsG/Wncn7fbL1T+ngGh6vLgj69LkKr7dqjZY3qE6qj6UDw0+NycenkL62YXTbHvvXLmWqVqG
 5SgKALlxyWl42l//lw3gB0QM5YO5CTKxzY1iHWMPI+SMqatFUXcSQg61nLysnsS6YNFnNymG/JmhD
 pK7stojQfTjp+zid1FG8vQqTF9EaL2wZgitTkSTOmQX+oiFKfAvsHLHCPVN29AgrapzPCK/pkS7U8
 xAFv7vGCbf2/7OZzAyr8JG8WH+1lwaiWhEiUTJ9qle2a+O712gRt+lcUTP/8KTP/ema/kOoMK2MOu
 mZ8BZBo7Ppo+v0H8oJOUhw==;
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 <eliz@HIDDEN>)
 id 1qKh5c-0003Fg-AY; Sat, 15 Jul 2023 11:21:44 -0400
Date: Sat, 15 Jul 2023 18:22:01 +0300
Message-Id: <83r0p9b3om.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sat, 15 Jul 2023 10:49:37 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  64596 <at> debbugs.gnu.org
> Date: Sat, 15 Jul 2023 10:49:37 -0400
> 
> > performance problem.  Because otherwise making changes in code that we
> > don't sufficiently understand can only cause bugs,
> 
> It can introduce bugs, but in my experience when dealing with code
> I don't understand, it's by breaking the code that you learn how it
> works, so saying "can only cause bugs" doesn't make sense.

It makes a lot of sense to me.  So let's agree to disagree here.  To
reiterate my firm opinion: either someone steps forward to work on
this seriously and systematically, or we should leave this code alone,
for better and for worse.

> The change can bring more clarity to the code, which is beneficial
> in the long term, and if it introduces bugs then presumably some
> users will see them, report them, and that will bring us better
> understanding of the code.

If someone wants to lead such a project for the next 10 years or so,
maybe.  But what happens in reality is that the breaking changes are
made, and then the "guilty parties" disappear into thin air, or lose
interest.  And we are left with a broken redisplay and an unfinished
project.

> That's eactly what happened when I introduced the 3 `redisplay` bits
> above: it did introduce a few bugs, but overall it made the code
> more clear.

No, that's not "exactly" what happened.  Some of the bugs popped up
much later, among other things.  I agree that the added comments made
the situation better, but you know as well as I do that some of the
aspects of those variables are still somewhat mysterious: specifically
the meaning of windows_or_buffers_changed and update_mode_lines for
disabling optimizations and shortcuts.  Which is exactly the focus of
the current discussion.

> > and guess who gets to work on fixing them.
> 
> AFAIK, for the bugs introduced by those `redisplay` bit: I did, as
> it should.

Not all of them.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 16:03:02 +0000
Resent-Message-ID: <handler.64596.B64596.168943692416527 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168943692416527
          (code B ref 64596); Sat, 15 Jul 2023 16:03:02 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 16:02:04 +0000
Received: from localhost ([127.0.0.1]:45831 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKhid-0004IU-SA
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 12:02:04 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:8038)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qKhiY-0004Hv-0G
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 12:02:01 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 183121000CA;
 Sat, 15 Jul 2023 12:01:52 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 03531100098;
 Sat, 15 Jul 2023 12:01:51 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689436911;
 bh=bNOg1d1tkQaqHjqFWcOLdXDpl+ySuJVF8Vop1PNgBcs=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=T4bCgZKSAfvPm5Owgbyra3Cvk5K01NizIkhKWQddL9GYR6NTct09+8ay7yKyM+LCX
 VCDwNE+xw7JFE9O+XE1mFsmVo1juqXDbvNDmMkBQ9EnzXqRc7RiJ3imVLU6Q9IIPF0
 s6mdFYhFV1Btz/jOX3+yCGjZ14jlgUlt3WGRE9DDGZr+WfnD/mXgwMFmrasD8fa0hd
 VimXMYlDZTZVNSUFX/hclr3qlPBNBXuTtLlYd7uzPDOAFUm4RSWENkoVLc0bpnEbwH
 k4zqnjT8QYSf9C8Y8yBEqoHb+qmKp2cGOM4sdO5tJZwbSjAzks9ylsc8L3P/BrRHZ4
 zVp4Ral3CdxBw==
Received: from pastel (unknown [108.175.230.17])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id CC2A312019A;
 Sat, 15 Jul 2023 12:01:50 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83r0p9b3om.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 15 Jul
 2023 18:22:01 +0300")
Message-ID: <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <83r0p9b3om.fsf@HIDDEN>
Date: Sat, 15 Jul 2023 12:01:50 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.131 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> But what happens in reality is that the breaking changes are made, and
> then the "guilty parties" disappear into thin air, or lose interest.
> And we are left with a broken redisplay and an unfinished project.

I didn't disappear into thin air, did I?

Maybe I shouldn't take this personally, but my `redisplay-bit` changes
are the only changes I'm aware of in this kind of vicinity, so I can't
help but feel that this experience is an important point of reference
for both of us.

>> That's eactly what happened when I introduced the 3 `redisplay` bits
>> above: it did introduce a few bugs, but overall it made the code
>> more clear.
> No, that's not "exactly" what happened.  Some of the bugs popped up
> much later, among other things.  I agree that the added comments made
> the situation better, but you know as well as I do that some of the
> aspects of those variables are still somewhat mysterious: specifically
> the meaning of windows_or_buffers_changed and update_mode_lines for
> disabling optimizations and shortcuts.  Which is exactly the focus of
> the current discussion.

Those aspects are not due to my changes.  If they are mysterious it's
because the remained mysterious, i.e. because I did not change them.

[ Actually, I did change them a bit to help track them down: I changed
  those vars from booleans to integers where the integer is a "code" for
  the place where it has been "mysteriously set".  And you can check
  `redisplay--all-windows-cause` and `redisplay--mode-lines-cause` to
  see how many times each of those "mysterious causes" has been
  used :-)  ]

This said, the meaning of those vars is clear, I think (they mean, that
all the windows/modelines need to be updated).
What still isn't clear at some places is the reason why they're set.

>> > and guess who gets to work on fixing them.
>> AFAIK, for the bugs introduced by those `redisplay` bit: I did, as
>> it should.
> Not all of them.

Admittedly, sometimes it's difficult to know beforehand whether the bug
may be due to those changes, so you may end up wasting your time before
you can redirect the bug to the appropriate person, but this is another
place where having that `internal--use-old-slow-redisplay` variable
would help.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 16:17:02 +0000
Resent-Message-ID: <handler.64596.B64596.168943781717823 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168943781717823
          (code B ref 64596); Sat, 15 Jul 2023 16:17:02 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 16:16:57 +0000
Received: from localhost ([127.0.0.1]:45836 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKhx2-0004dP-EY
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 12:16:56 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:54168)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKhwx-0004d9-55
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 12:16:55 -0400
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 <eliz@HIDDEN>)
 id 1qKhwq-0003Pm-56; Sat, 15 Jul 2023 12:16: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=SAPm0ps647UI4HvrdeeKQx74ma3SdMiPWH2XXqE/AGg=; b=HLofgL+TwzOL
 zdTTZcMXojUL/fGH1crPbYtYSdvORU50y/7vpsbnx+HCKBW7Wh1cRQGinmKMMzDPtANokAAGuZY88
 hAoFO5Np7tdYeSWbcwPzmBI5aS+MNh1YJf0Cbai3vg+xLJT9pcLRjoxKNohLsmadFC334Nm7npydz
 8A3p9kyWtsD/g6mJWwUxBfAiB/w9YdvZYBOrw987Q/cSm1tZGlaAyeJPEtfJU8gaGVSkwwnBHxV9d
 Yk2RYo9jF+K+lpqOhbl7cHRVhS7PBzJmmDVGbhgO2HRHH6rWw6y38veWUUjxsN6Y9YxKs75PFOT17
 g+MEmv+AXXvzJ8nBljrGHw==;
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 <eliz@HIDDEN>)
 id 1qKhwh-00018L-Bk; Sat, 15 Jul 2023 12:16:43 -0400
Date: Sat, 15 Jul 2023 19:16:57 +0300
Message-Id: <83jzv1b152.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sat, 15 Jul 2023 12:01:50 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  64596 <at> debbugs.gnu.org
> Date: Sat, 15 Jul 2023 12:01:50 -0400
> 
> > But what happens in reality is that the breaking changes are made, and
> > then the "guilty parties" disappear into thin air, or lose interest.
> > And we are left with a broken redisplay and an unfinished project.
> 
> I didn't disappear into thin air, did I?

Let's not make this too personal.  Suffice it to say that I saw more
than once or twice changes in these areas which caused subtle
redisplay problems several years later, and I did have to fix a few of
them.  So what I wrote is based on facts and actual experience.

> >> That's eactly what happened when I introduced the 3 `redisplay` bits
> >> above: it did introduce a few bugs, but overall it made the code
> >> more clear.
> > No, that's not "exactly" what happened.  Some of the bugs popped up
> > much later, among other things.  I agree that the added comments made
> > the situation better, but you know as well as I do that some of the
> > aspects of those variables are still somewhat mysterious: specifically
> > the meaning of windows_or_buffers_changed and update_mode_lines for
> > disabling optimizations and shortcuts.  Which is exactly the focus of
> > the current discussion.
> 
> Those aspects are not due to my changes.  If they are mysterious it's
> because the remained mysterious, i.e. because I did not change them.

Indeed.  The above wasn't written to accuse, but to convey the fact
that we are not yet where we want to be in this regard.

> This said, the meaning of those vars is clear, I think (they mean, that
> all the windows/modelines need to be updated).

Not entirely true, AFAIU.  For example, what does update_mode_lines
have to do with preparing the menu bar?

  static void
  prepare_menu_bars (void)
  {
    bool all_windows = windows_or_buffers_changed || update_mode_lines;
    bool some_windows = REDISPLAY_SOME_P ();

or a similar reference in update_menu_bar.

Or why redisplay_internal does this:

  consider_all_windows_p = (update_mode_lines
			    || windows_or_buffers_changed);

And a couple of more "questionable" uses of that variable.

> What still isn't clear at some places is the reason why they're set.

Yes, that too.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 17:16:01 +0000
Resent-Message-ID: <handler.64596.B64596.168944135223748 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168944135223748
          (code B ref 64596); Sat, 15 Jul 2023 17:16:01 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 17:15:52 +0000
Received: from localhost ([127.0.0.1]:45864 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKis4-0006Ay-6s
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 13:15:52 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:30716)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qKirz-0006Ag-Ua
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 13:15:51 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id A61C18065C;
 Sat, 15 Jul 2023 13:15:42 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 510FF805DE;
 Sat, 15 Jul 2023 13:15:41 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689441341;
 bh=xzSgMR3y3iaHrBZAb1tquiLtiAQpr4CJySvHnOkYqXk=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=foG9SO/O6sB2+hb38zcNUoSxcTiX9/TolFcSHTk6ECPD3OrXBwqnzFZwIpIwYJnBG
 4uf2XJrpxw7SNeIApDRctCJxmOKDvkULutIRDKJ5CTkHxFMADrzYhPwgkgpzkREDv2
 dWDZYbKG3AsC6nTJMFLGzxu4NWiaOLo8mkAyENFeBJbk6Ajw30akHY8f7CRM42u7j3
 eEytMz2W32lS+Da0k9FtVAd95pqnqHj++nf6amK7/yAjv+KLg19S7b+ixRbiGCVBcT
 cSssJ1YmbvVyuD36c1bK/g1VtkUCpq3goiiKFXvwGbvmLJX6UamUnh2csucLlQmHBB
 PM2J4jJNYl2OQ==
Received: from pastel (unknown [108.175.230.17])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 249CD12034B;
 Sat, 15 Jul 2023 13:15:41 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83jzv1b152.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 15 Jul
 2023 19:16:57 +0300")
Message-ID: <jwvilalayz0.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
 <83jzv1b152.fsf@HIDDEN>
Date: Sat, 15 Jul 2023 13:15:39 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.083 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Not entirely true, AFAIU.  For example, what does update_mode_lines
> have to do with preparing the menu bar?
>
>   static void
>   prepare_menu_bars (void)
>   {
>     bool all_windows = windows_or_buffers_changed || update_mode_lines;
>     bool some_windows = REDISPLAY_SOME_P ();

Indeed `update_mode_lines` means more than just mode-lines.  It includes
of course header-lines (of course), frame names (less obvious), and also
the menu-bar, and some of those links are indeed not 100% clear.

WDYT about the patch below?
I'll try to update the docs to clarify this.


        Stefan


diff --git a/src/window.h b/src/window.h
index 2f793ebe438..48d3fd3dc82 100644
--- a/src/window.h
+++ b/src/window.h
@@ -1114,9 +1114,12 @@ #define WINDOW_TEXT_TO_FRAME_PIXEL_X(W, X)	\
 
 extern Lisp_Object echo_area_window;
 
-/* Non-zero if we should redraw the mode lines on the next redisplay.
+/* Non-zero if we should redraw the mode line*s* on the next redisplay.
    Usually set to a unique small integer so we can track the main causes of
-   full redisplays in `redisplay--mode-lines-cause'.  */
+   full redisplays in `redisplay--mode-lines-cause'.
+   Here "mode lines" includes also header-lines and frame names, and
+   apparently also menu-bars.  The link with header-lines is clear,
+   but a bit less so for frame names and the menu-bar.  */
 
 extern int update_mode_lines;
 
@@ -1134,6 +1137,11 @@ #define WINDOW_TEXT_TO_FRAME_PIXEL_X(W, X)	\
 extern void wset_redisplay (struct window *w);
 extern void fset_redisplay (struct frame *f);
 extern void bset_redisplay (struct buffer *b);
+
+/* Routines to indicate that the mode-lines might need to be redisplayed.
+   Just as for `update_mode_lines`, this includes header-lines, frame names
+   and menu-bars, and the link with frame names and menu-bars is still
+   unclear.   */
 extern void bset_update_mode_line (struct buffer *b);
 extern void wset_update_mode_line (struct window *w);
 /* Call this to tell redisplay to look for other windows than selected-window

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 18:16:02 +0000
Resent-Message-ID: <handler.64596.B64596.168944495930752 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168944495930752
          (code B ref 64596); Sat, 15 Jul 2023 18:16:02 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 18:15:59 +0000
Received: from localhost ([127.0.0.1]:46064 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKjoF-0007zw-3J
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 14:15:59 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:12203)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qKjoA-0007zT-3A
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 14:15:57 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D24B080327;
 Sat, 15 Jul 2023 14:15:48 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8E184801B3;
 Sat, 15 Jul 2023 14:15:43 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689444943;
 bh=RJQgviS1hhSkoO+ZHAR+r2kh59nvxAfnSpNhXhbY0eM=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=Z8Onog/JC8CYobmqGR/mEjt9qUUbobpW5/pzUqoDsAFOZFVN4opYDIIJRZmAMOT9P
 LdH5cs7oTH2H3Tswt/DQyqfxZRX2XGaWmeHtwS3IpgwwQp2RtlvWmDtqtn9+ANr3cO
 Y6GMepH49jIu/fqVNQFETDUWscMFHIZdMIdrOphnc66WFSji2m5pUgSqL73zAkmiaf
 CCojDQKUQ76XOp1qrTT9a2gj6xceVpb297TAh2OpahO0M04h0/ZhBgWRawiTYpteQJ
 F4H+/oAOMiWoA6vLlf7yklWe5sqSJamKI81r/Z+Q7ynfD7MhQyFygwobzexcVQlODy
 NHJUjuBGc1h9w==
Received: from pastel (unknown [108.175.230.17])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 10B791202F2;
 Sat, 15 Jul 2023 14:15:42 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83jzv1b152.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 15 Jul
 2023 19:16:57 +0300")
Message-ID: <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
 <83jzv1b152.fsf@HIDDEN>
Date: Sat, 15 Jul 2023 14:15:41 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.062 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Or why redisplay_internal does this:
>
>   consider_all_windows_p = (update_mode_lines
> 			    || windows_or_buffers_changed);

Sorry, I skipped this part in my previous email.
I understand the above code, but I'm not sure what explanation might
be needed so you can understand it as well.  Maybe the problem is the
name `consider_all_windows_p` which suggests that all windows will be
updated, but it only says that we should loop through all the windows to
try and find those which need to be updated.

Would the patch below help?


        Stefan


diff --git a/src/xdisp.c b/src/xdisp.c
index a3464c2c375..385569d9309 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -16491,7 +16491,9 @@ redisplay_internal (void)
   int garbaged_frame_retries = 0;
 
   /* True means redisplay has to consider all windows on all
-     frames.  False, only selected_window is considered.  */
+     frames.  False, only selected_window is considered.
+     If true, the set of windows we try to update is further limited
+     according to the `redisplay` bits in buffers/windows/frames.  */
   bool consider_all_windows_p;
 
   /* True means redisplay has to redisplay the miniwindow.  */

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 19:06:01 +0000
Resent-Message-ID: <handler.64596.B64596.16894479103297 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16894479103297
          (code B ref 64596); Sat, 15 Jul 2023 19:06:01 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 19:05:10 +0000
Received: from localhost ([127.0.0.1]:46087 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKkZp-0000r6-JL
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:05:10 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:57134)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKkZm-0000qb-K5
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:05:07 -0400
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 <eliz@HIDDEN>)
 id 1qKkZg-0006rx-Ja; Sat, 15 Jul 2023 15:05:00 -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=nNb2FLomul02H6nWN1uwvrVTC80OghQVgNBFsN6/4vQ=; b=DRXmwcjlBo5P
 gvFCv8cFnlbu1YvBQMCrIIiKPUn8NuzfTmax/xtKxPSWf2pT+kFhWMbWextOzUZ7Ipj+JGA8ISW9F
 DfLdA0cGP22QE8A4gagwwURSKEl6G2/9hwqEkXSAL/C1/UYcVxr/kDXmUF9psS0xHnNXoj18MHzWS
 J4xGO5IbooieZui338qlEJkaV+x0qxuP+U1oDtCCezaRLjMuOUqIW7f0GbQGcghn+PrBeEivWkQiN
 2ZXrrsby5/CbfH+QOHad6SwZnNMwBsa3nV4mjjASBtnPX0PLEJBUdWo6kRiq6ras8CmWqIXIPhF5h
 l1Pus1cFoEreP98kk2B/8A==;
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 <eliz@HIDDEN>)
 id 1qKkZI-0000XU-W5; Sat, 15 Jul 2023 15:04:52 -0400
Date: Sat, 15 Jul 2023 22:04:53 +0300
Message-Id: <83h6q5atd6.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvilalayz0.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sat, 15 Jul 2023 13:15:39 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
 <83jzv1b152.fsf@HIDDEN> <jwvilalayz0.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  64596 <at> debbugs.gnu.org
> Date: Sat, 15 Jul 2023 13:15:39 -0400
> 
> > Not entirely true, AFAIU.  For example, what does update_mode_lines
> > have to do with preparing the menu bar?
> >
> >   static void
> >   prepare_menu_bars (void)
> >   {
> >     bool all_windows = windows_or_buffers_changed || update_mode_lines;
> >     bool some_windows = REDISPLAY_SOME_P ();
> 
> Indeed `update_mode_lines` means more than just mode-lines.  It includes
> of course header-lines (of course), frame names (less obvious), and also
> the menu-bar, and some of those links are indeed not 100% clear.
> 
> WDYT about the patch below?

That's an improvement, thanks.  But it still isn't everything.  For
example, what about resize_echo_area_exactly: why does it set this
variable?  Also, this variable is tested in update_tool_bar and
update_tab_bar, so the comment you suggest should mention tool bar and
tab bar as well.  Unless you know the answers to these questions, I
guess more digging is in order.

And I'd be happier if, instead of a single variable for so many
purposes we would have either several separate variables or make this
one a bitmap, where each bit says something very specific about the
part of the display that needs updating.  Any takers?

> -/* Non-zero if we should redraw the mode lines on the next redisplay.
> +/* Non-zero if we should redraw the mode line*s* on the next redisplay.
>     Usually set to a unique small integer so we can track the main causes of
> -   full redisplays in `redisplay--mode-lines-cause'.  */
> +   full redisplays in `redisplay--mode-lines-cause'.
> +   Here "mode lines" includes also header-lines and frame names, and
> +   apparently also menu-bars.  The link with header-lines is clear,
> +   but a bit less so for frame names and the menu-bar.  */

Btw, we need some function to show the information in
redisplay--mode-lines-cause in human-readable format, or at least a
documentation for how to examine it.  Without that, this variable is
probably useful only to a very small group of people.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 19:19:01 +0000
Resent-Message-ID: <handler.64596.B64596.16894487064489 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16894487064489
          (code B ref 64596); Sat, 15 Jul 2023 19:19:01 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 19:18:26 +0000
Received: from localhost ([127.0.0.1]:46105 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKkmg-0001AL-Cf
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:18:26 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:42744)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKkmd-0001A7-NC
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:18:24 -0400
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 <eliz@HIDDEN>)
 id 1qKkmY-0002Eg-8O; Sat, 15 Jul 2023 15:18: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=4YAYeV9DKtl1DKnROyykwsm9KFwtjaHOlkscQxffw3Y=; b=OkiJkKRlVd9i
 jd5dc+QKGijQ5KNRqE2Eg9sVE6eNJSXERJ/Ru72gPnYseDwrys6yHYs7jtYFcardEEzcBIS7Cn5ve
 Fl9k1U7HKVGIWhodxFWx3oUz/9WN3CI2eHNE3B4REzSqV/m+jKZA9ZYM9qgn7DAE804w6VZW+Oo/3
 iiEg0KLWsDOV4TTZoyf4feQA4oI6GiawbjOOKTRoLJydXpsdngnG9HEMNRuJHm0z/f5vicgZQK2Sm
 Ulqi/QGi2cRPC4BOseSwbPPs8jJ6vSPcXoF6u3NrOHMcEVMHa8XeQ/3GR1Zxq0dUgp1t93GKcFQcR
 eKW340X7PSQPmR5LlYcYAw==;
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 <eliz@HIDDEN>)
 id 1qKkmX-0001pQ-On; Sat, 15 Jul 2023 15:18:18 -0400
Date: Sat, 15 Jul 2023 22:18:40 +0300
Message-Id: <83cz0tasq7.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sat, 15 Jul 2023 14:15:41 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
 <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  64596 <at> debbugs.gnu.org
> Date: Sat, 15 Jul 2023 14:15:41 -0400
> 
> > Or why redisplay_internal does this:
> >
> >   consider_all_windows_p = (update_mode_lines
> > 			    || windows_or_buffers_changed);
> 
> Sorry, I skipped this part in my previous email.
> I understand the above code, but I'm not sure what explanation might
> be needed so you can understand it as well.  Maybe the problem is the
> name `consider_all_windows_p` which suggests that all windows will be
> updated, but it only says that we should loop through all the windows to
> try and find those which need to be updated.
> 
> Would the patch below help?

It probably would.  (The meaning of the variable was clear to me
before this, but maybe it will help others.)

Thanks.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 19:29:02 +0000
Resent-Message-ID: <handler.64596.B64596.16894493045384 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16894493045384
          (code B ref 64596); Sat, 15 Jul 2023 19:29:02 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 19:28:24 +0000
Received: from localhost ([127.0.0.1]:46118 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKkwK-0001Om-Bf
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:28:24 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:44754)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKkwI-0001OZ-Kt
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:28:23 -0400
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 <eliz@HIDDEN>)
 id 1qKkwD-00056y-Ao; Sat, 15 Jul 2023 15:28:17 -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=8Nhr0hTD8QreDN5PAa9lS65D6nZ1ZKcNewZ3d88NIOU=; b=Y/mUu1K5IEPS
 nIGGpEjP64bCiPKEGcP0MxqbClwgl0iR/5gKlBDHn/JVJcAkZVfGrcD+8taqHiKpNk5EJ+0JLsfIT
 Cz608R696CY1W7frbVTP5r0RrNfghOBwI2tjUmv5+KlaCMIZKjakp6ksMBlTP6uw5d6vpXYD+TwOb
 HZqLrcjB9n18O5DW3iD5k7L+HXuiRTtGSPsf+f93tB5aH2T73QZC0q4rXUNZ32+6Nvp8n7Cd1riGx
 /EAPuIuH3oKrko0mKT5GwAtWf/4Q+Ed80WyKD5gyBs01eRN+dzH3AfWyFGCetK3+CCdDyA82GQL5q
 qTjdqPi93L4U+zsWpVSJJA==;
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 <eliz@HIDDEN>)
 id 1qKkwC-0005Uz-Op; Sat, 15 Jul 2023 15:28:17 -0400
Date: Sat, 15 Jul 2023 22:28:39 +0300
Message-Id: <83a5vxas9k.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sat, 15 Jul 2023 14:15:41 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
 <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  64596 <at> debbugs.gnu.org
> Date: Sat, 15 Jul 2023 14:15:41 -0400
> 
> > Or why redisplay_internal does this:
> >
> >   consider_all_windows_p = (update_mode_lines
> > 			    || windows_or_buffers_changed);
> 
> Sorry, I skipped this part in my previous email.
> I understand the above code, but I'm not sure what explanation might
> be needed so you can understand it as well.  Maybe the problem is the
> name `consider_all_windows_p` which suggests that all windows will be
> updated, but it only says that we should loop through all the windows to
> try and find those which need to be updated.

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?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 19:44:01 +0000
Resent-Message-ID: <handler.64596.B64596.16894502016956 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16894502016956
          (code B ref 64596); Sat, 15 Jul 2023 19:44:01 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 19:43:21 +0000
Received: from localhost ([127.0.0.1]:46138 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKlAn-0001o7-CQ
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:43:21 -0400
Received: from mout02.posteo.de ([185.67.36.66]:37691)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qKlAl-0001nt-LV
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 15:43:20 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 8010C240101
 for <64596 <at> debbugs.gnu.org>; Sat, 15 Jul 2023 21:43:13 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689450193; bh=oh2TJJryrxapV4cSw7ocrYEMQSCwugJHsAB1KKLlNw0=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=K69GxFVa6yq7WUBo0vYLU1LJ9WEr5S1y325KTw+jSu6dep1Y1nNr/LaQW+NjEqB7f
 ZYagGP2ZXbQji8+ukoaez0j0Nzgl6l6FwQ6VFcAXGP86Q5dciypMuzalLAxTpTeW8k
 P1B1WPtLsvJnOD4GS61JIba6Razt1rVddq7zRadwgcZ4a5vchrW7YbTbLj8AJ6nI4D
 oyZJojdMbIha3RIm2ofkx5VufIKhNxAD/faQU7EHBP1tTHtIb9uMnvgmbqxkIdz+59
 DYk0JlUhDkCtPABCRO6u5QogQYaERRwh3p0BQ3jMimap63ZINUMKwbWLITEAlvv/gw
 6wPCvs3cXZ91w==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R3Jfm4lwfz6twR;
 Sat, 15 Jul 2023 21:43:12 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <83a5vxas9k.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
Date: Sat, 15 Jul 2023 19:43:17 +0000
Message-ID: <877cr1nep6.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> 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.

Compare bset_redisplay and bset_update_mode_line.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 22:54:01 +0000
Resent-Message-ID: <handler.64596.B64596.16894616133905 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16894616133905
          (code B ref 64596); Sat, 15 Jul 2023 22:54:01 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 22:53:33 +0000
Received: from localhost ([127.0.0.1]:46240 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKo8q-00010u-Lx
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 18:53:32 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:38950)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qKo8l-00010d-Gt
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 18:53:31 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id DE8E380065;
 Sat, 15 Jul 2023 18:53:21 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id D53F6801B3;
 Sat, 15 Jul 2023 18:53:20 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689461600;
 bh=SxdmDD+vgzHQ86JcdkDNX5BMMkJIc/tcKWHbNYQxgSE=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=jAxghVCYI2vKX5wtKJIz8k6WZCwTX9/09nNTQDM2njp01cRLUM7jMWthSG5z5bIvY
 zLlbnjDT4QRGGW1bOsxgLD6heqz+UcRdtPR/eGsA9QAfRaxVBhuDGtDYxL2/7sxPxQ
 vBtTxPPFjmAoUomWY2RVSytm+l1z+354IwALQ1otlLnDTQrLl7H2mKwhr2L5jS+PUu
 bBKTdd4X3DvAm37pisjmHDRCwi6ibDMHepqsBNyDcPuF/Hg4pR8oEllcV3J1qI+T33
 CtRV7MK3x3AvTqR27TjnmptApJbQiTcy4ptkTDyB+AR1rarbxaTDvvTtD9rcLFGlnY
 ghZJTVeu0FG6g==
Received: from pastel (unknown [104.247.238.169])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id ABA721201FF;
 Sat, 15 Jul 2023 18:53:20 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83a5vxas9k.fsf@HIDDEN> (Eli Zaretskii's message of "Sat, 15 Jul
 2023 22:28:39 +0300")
Message-ID: <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
 <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
 <83a5vxas9k.fsf@HIDDEN>
Date: Sat, 15 Jul 2023 18:53:19 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> Sorry, I skipped this part in my previous email.
>> I understand the above code, but I'm not sure what explanation might
>> be needed so you can understand it as well.  Maybe the problem is the
>> name `consider_all_windows_p` which suggests that all windows will be
>> updated, but it only says that we should loop through all the windows to
>> try and find those which need to be updated.
>
> 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").

How 'bout the wording below, then?


        Stefan


diff --git a/src/xdisp.c b/src/xdisp.c
index a3464c2c375..13f4fbca074 100644
--- a/src/xdisp.c
+++ b/src/xdisp.c
@@ -16490,8 +16490,10 @@ redisplay_internal (void)
   enum {MAX_GARBAGED_FRAME_RETRIES = 2 };
   int garbaged_frame_retries = 0;
 
-  /* 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;
 
   /* True means redisplay has to redisplay the miniwindow.  */

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sat, 15 Jul 2023 23:11:02 +0000
Resent-Message-ID: <handler.64596.B64596.16894626275524 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16894626275524
          (code B ref 64596); Sat, 15 Jul 2023 23:11:02 +0000
Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 23:10:27 +0000
Received: from localhost ([127.0.0.1]:46245 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKoPD-0001R2-Cz
	for submit <at> debbugs.gnu.org; Sat, 15 Jul 2023 19:10:27 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:60038)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qKoP9-0001Qj-S2
 for 64596 <at> debbugs.gnu.org; Sat, 15 Jul 2023 19:10:26 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 95FD28065C;
 Sat, 15 Jul 2023 19:10:18 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 8F881805DE;
 Sat, 15 Jul 2023 19:10:17 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689462617;
 bh=U1dfbkM0UQfa/ILHec4hu/Bz3ioXQe6MPvnIFb51HMc=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=LRyv8hzWaVxh2srW7Oj9z8QTUhJB3wzp4OzsE2yu8waWMpbXekDhAnOjP467sTFt+
 BOnZkAuCvPkyq+Uc7CNqj2BEtlGUNSeUqhtUcQbk1diNCCkGz6IKu8C88Iu9d1vhzQ
 PIDurAdt8KBpDQe6SR4TJXLaJd+rL9tIoNmGhj9LYzgQQOrPxenW2RYjzpMlgvlGfa
 CVOqdXHydcQYKa9YQ16anN475qRw9gn8P4qMLWgI3kp3FuQKltWfewc/6uqbij8Q5z
 ObecoQIgcRgYkl05X2XKEqgkswuoNeyqq5oMFXrD1E/4W5g7eOKOq4CT0jw2kl0FPB
 XpUxW77SaB3Xw==
Received: from pastel (unknown [104.247.238.169])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 65E2B120165;
 Sat, 15 Jul 2023 19:10:17 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <877cr1nep6.fsf@localhost> (Ihor Radchenko's message of "Sat, 15
 Jul 2023 19:43:17 +0000")
Message-ID: <jwvr0p8aisb.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
 <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
 <83a5vxas9k.fsf@HIDDEN> <877cr1nep6.fsf@localhost>
Date: Sat, 15 Jul 2023 19:10:16 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> 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.

Indeed, we have a special case for that.  Before my change, it was
either "just the selected window" or "all windows".

> Compare bset_redisplay and bset_update_mode_line.

Indeed the old code updated all windows after a call to
`force-mode-line-update` even if the current buffer is only displayed in
the selected window and I somewhat preserved that :-(


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 04:57:02 +0000
Resent-Message-ID: <handler.64596.B64596.16894834138360 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16894834138360
          (code B ref 64596); Sun, 16 Jul 2023 04:57:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 04:56:53 +0000
Received: from localhost ([127.0.0.1]:46367 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKtoT-0002Al-5k
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 00:56:53 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:59204)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKtoQ-0002AV-DM
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 00:56:51 -0400
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 <eliz@HIDDEN>)
 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==;
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 <eliz@HIDDEN>)
 id 1qKtoJ-0004SJ-No; Sun, 16 Jul 2023 00:56:44 -0400
Date: Sun, 16 Jul 2023 07:57:07 +0300
Message-Id: <835y6kbgik.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <877cr1nep6.fsf@localhost> (message from Ihor Radchenko on Sat,
 15 Jul 2023 19:43:17 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <877cr1nep6.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Stefan Monnier <monnier@HIDDEN>, 64596 <at> debbugs.gnu.org
> Date: Sat, 15 Jul 2023 19:43:17 +0000
> 
> Eli Zaretskii <eliz@HIDDEN> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 05:18:02 +0000
Resent-Message-ID: <handler.64596.B64596.168948463210852 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168948463210852
          (code B ref 64596); Sun, 16 Jul 2023 05:18:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 05:17:12 +0000
Received: from localhost ([127.0.0.1]:46382 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKu87-0002ox-4w
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 01:17:12 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:51338)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKu81-0002oM-OA
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 01:17:09 -0400
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 <eliz@HIDDEN>)
 id 1qKu7t-0000ed-QB; Sun, 16 Jul 2023 01:16:57 -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=djeeENSdKel2rwfUnBMyv7fOOZzJKi461iim1kLtq+4=; b=seBXyuBmI44L
 6ZvnOxkjdT3tEY/RubxgLcQo7u+fHY6JEJ1mXny2KqHudKKdu7qHrKnrqipn7xZfq2STPwwJVh5hj
 fP5KeEA419CyDth0yNfN6OMluLJxeOLMjZgtwpOIgs9g/OmAddM7retYG78d/iO2BHIDS579RHrxw
 OK2gEgu7uDNdg5LgtFKiH9JTHjG2agBU2rebFZMLwC/r+/z1DmO/aID8738HM+/OdIdvhN6K40PwP
 jP0nR53NUU6JdWKNNg1ev/nNQ1VDS9kP9We6Buu4zODMJXBaMHqN3nTicNhl9QS0OpAL50yCb1U3w
 aZUHkSNfLDdM5tln9uNCjg==;
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 <eliz@HIDDEN>)
 id 1qKu7r-0003D1-KN; Sun, 16 Jul 2023 01:16:57 -0400
Date: Sun, 16 Jul 2023 08:17:19 +0300
Message-Id: <83zg3wa10g.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sat, 15 Jul 2023 18:53:19 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
 <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
 <83a5vxas9k.fsf@HIDDEN> <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  64596 <at> debbugs.gnu.org
> Date: Sat, 15 Jul 2023 18:53:19 -0400
> 
> > 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").
> 
> How 'bout the wording below, then?

OK, provided that you remove that redundant comma

> +  /* False, means that only the selected_window needs to be updated.
             ^
there.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 05:50:02 +0000
Resent-Message-ID: <handler.64596.B64596.168948659214444 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168948659214444
          (code B ref 64596); Sun, 16 Jul 2023 05:50:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 05:49:52 +0000
Received: from localhost ([127.0.0.1]:46400 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKudj-0003ku-Lt
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 01:49:51 -0400
Received: from mout02.posteo.de ([185.67.36.66]:49407)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qKudf-0003ka-A4
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 01:49:50 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 5D3A2240103
 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 07:49:41 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689486581; bh=ADE8PfVsGdNHizkB4cSDWudkIHsdaucPnACEp2FsOnE=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=fbSpTdWVlXUQsDwAnhS0ytRyb627Kn7aQ75xTnF1dNJxE+D9dBoUvFIuk6CCia5Qv
 pWMKIKDh2v8+mIVNqQ16k0WJ7zvpmMbrUBsD1cyFGZkbaFbiVH6YmkZWw8yDTkBd42
 Pt4LTAkvwWIMUFa5M7EVcBxDbWiRi/vbruO3+kc29RZXhhf1Mpr3ezbP22OGkMeN6p
 j04bL+YS51Cr8EOxk8eFUELk7SL6dG2wDL35A1MOMeGgAMpQE2V2kHIEtb+HZBmhTz
 1vVbU4kM26Y+knMhTrkpD0osVPtnQ0h9sqLC2SOVjooF2z1MqScg4WZRNhAbY3nhpN
 qGwpCVubUd+ow==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R3Z6V3X3mz6txj;
 Sun, 16 Jul 2023 07:49:38 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <835y6kbgik.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 05:49:45 +0000
Message-ID: <874jm4o16u.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

>> 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.

If the selected window changes for any reason, redisplaying the
previously selected window will be queued by select_window:

  if (NILP (norecord) || EQ (norecord, Qmark_for_redisplay))
    { /* Mark the window for redisplay since the selected-window has
	 a different mode-line.  */
      wset_redisplay (XWINDOW (selected_window)); 
      wset_redisplay (w);
    }
  else
    redisplay_other_windows ();

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 05:52:02 +0000
Resent-Message-ID: <handler.64596.B64596.168948672115466 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168948672115466
          (code B ref 64596); Sun, 16 Jul 2023 05:52:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 05:52:01 +0000
Received: from localhost ([127.0.0.1]:46404 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKufp-00041O-70
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 01:52:01 -0400
Received: from mout02.posteo.de ([185.67.36.66]:60981)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qKufm-000415-K4
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 01:51:59 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 1822A240103
 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 07:51:53 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689486713; bh=cHkSOdtApEdfNQtwrf92qQ03LQATzP0/RbLcmhD1gRA=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=BRnX4YllZBGyMeqz6te+rthElTjtwN5qlZ82pMOgknKmbIBEGcl6NSACzQs3XA7y1
 V3IE4buBCvkBHnfSTgAKFlS7Gvx2FPCWJbpJukyPzuM1D+ON8QfpHyG59AdZO8ghOF
 xUrcSA3vY0onGT8WVuNhKlZv+xQfNgY6Mf87xcdyDuS/1tzHhpbQHsTGYsju+sDYe0
 ZC4Yc69O3WRUF8foEO/rKvkjNq3nMf2rj8wiGOuOvZZSWqwYUDfl1wlFleGwnb4JND
 cyD5CcQUZ2zUtpYGavMclkGZm+EMUcsL06/9emUtL7POMjKYGtHAhzVORJq4psvEza
 z0LDKKbfti22A==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R3Z942tkHz9rxF;
 Sun, 16 Jul 2023 07:51:52 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN>
Date: Sun, 16 Jul 2023 05:52:04 +0000
Message-ID: <871qh8o12z.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Stefan Monnier <monnier@HIDDEN> writes:

> -  /* 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?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 07:16:01 +0000
Resent-Message-ID: <handler.64596.B64596.168949171724998 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168949171724998
          (code B ref 64596); Sun, 16 Jul 2023 07:16:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 07:15:17 +0000
Received: from localhost ([127.0.0.1]:46537 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKvyM-0006V5-KH
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:15:17 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:45432)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKvyJ-0006Uo-SZ
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:15:13 -0400
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 <eliz@HIDDEN>)
 id 1qKvyE-0004Xj-2x; Sun, 16 Jul 2023 03:15:06 -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=xK8EFX5/ypo3HFJr5BPjQjJTkG44TO2A5jBfdSX4KkM=; b=gg2+rAzz0aS8
 l6AcySKQxDHHfA2qPSqNwRWg8yhm8aSh0uorN9zq3de2n/Ej43GotweVm5F551UnzlVb9VP2paFTS
 c788l7QzyTmGbvkxPgxqqM4lQfoRqsNxprMDF8AEJfhEBjaYMPtRsoFXo09vnjGq1RCcD2epx7TLR
 IPJKtN83mXqOa7ztkBHFRBYPcuytaVLUADrqIqekGGOODIndVnFRT/WJvi7+rGe0ahWBgM+Jrit8h
 wO3owL0wvLrdYt0PwgkQZ3YBWbR3Koz5IDz7NS1BpwqAr9Hd3sR2R/NmHEm5k6ULQSg/E8gctfvxl
 yoDF0+Co5UXrmMFrVc/3nA==;
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 <eliz@HIDDEN>)
 id 1qKvyD-0005PR-Fc; Sun, 16 Jul 2023 03:15:05 -0400
Date: Sun, 16 Jul 2023 10:15:28 +0300
Message-Id: <83v8ek9vjj.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <874jm4o16u.fsf@localhost> (message from Ihor Radchenko on Sun,
 16 Jul 2023 05:49:45 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN> <874jm4o16u.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 05:49:45 +0000
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> >> 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.
> 
> If the selected window changes for any reason, redisplaying the
> previously selected window will be queued by select_window:

Yes, but what does this have to do with what I wrote?

My point is that where we set update_mode_lines we cannot yet know
whether only the selected window will have to be redisplayed.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 07:17:02 +0000
Resent-Message-ID: <handler.64596.B64596.168949178025141 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168949178025141
          (code B ref 64596); Sun, 16 Jul 2023 07:17:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 07:16:20 +0000
Received: from localhost ([127.0.0.1]:46546 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKvzP-0006XQ-KO
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:16:19 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:53794)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKvzO-0006XC-0N
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:16:18 -0400
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 <eliz@HIDDEN>)
 id 1qKvzI-0004iP-QA; Sun, 16 Jul 2023 03:16:12 -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=b9LxLShADQXCJ0g7IcdlyL1gCmX6QiiPFiM/sm0T/J4=; b=T1MEUoqdZVoX
 XOO/WFnMP7RaWUPKwLOpWnU5iQvhqQt1px0o2/nFFYOET7W1KwasZ3iYnrRwSNwfd9A1PxDwrzQtq
 ZeYvYclZJu7ABTNDXj4EX64GgB/APl+oHcqYMlr6xx5zG6AXfVbOdD3OliBj02QN/cA8kPEDYwXcA
 XoYDUufvp12sIO8mOKazXZxCGpBCiE15eX3t/5pYD02hjyjnAl1hcTGqwy/YBOOUdORsneI6rvz/B
 o7FAIyIUbGQo/ETYQqVHckKnXlYSS4+KvgYYWU+VNNtGMEu/73oJx5wnrVyoernlExxihXh7OG3Fy
 bG37x2zYbmw8TTV0TYtO5w==;
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 <eliz@HIDDEN>)
 id 1qKvzI-0005bX-Aw; Sun, 16 Jul 2023 03:16:12 -0400
Date: Sun, 16 Jul 2023 10:16:36 +0300
Message-Id: <83ttu49vhn.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <871qh8o12z.fsf@localhost> (message from Ihor Radchenko on Sun,
 16 Jul 2023 05:52:04 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN> <871qh8o12z.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 05:52:04 +0000
> 
> Stefan Monnier <monnier@HIDDEN> writes:
> 
> > -  /* 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?

Why do we need such a queue, when the redisplay flags of buffers and
windows are supposed to tell us that already?

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 07:29:02 +0000
Resent-Message-ID: <handler.64596.B64596.168949248626497 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168949248626497
          (code B ref 64596); Sun, 16 Jul 2023 07:29:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 07:28:06 +0000
Received: from localhost ([127.0.0.1]:46602 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKwAo-0006tI-3j
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:28:06 -0400
Received: from mout01.posteo.de ([185.67.36.65]:37189)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qKwAl-0006sm-Nh
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:28:04 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 05D84240027
 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 09:27:58 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689492478; bh=2nH/j/WTNFa8sbCbzpjPe88ZWfTBOr2CIjOwZ73ikIM=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=EAZlcePZ8ytxLO1dlMTsUP7uuZvahxMFfZego+ecs7NylzT2xKDYIw8jJZyVwLpCE
 svx5oWyxlEaFSzuqn4bMiNVpwM9mP8/sfObZpRXoPY7d4ueZvz/nF5Cy1BcTVUTVAS
 MH4V2HsOvuC4zvbC7VZj8DCY7KYrM3aTc/lTlOITbVUpMWqZRGsHlkBjYfQ2CqT4rw
 xifVp795oul9pqUQpFKTrQui+JW8EJ0CGpd6vRrGU7bbU6Chx0c0BeKrHOVoBsfnMM
 velOZTxTtFP+OZe3s3Wh6iKmAhHTeATSI1rwnFxJ/0S50ixKCSKEenPYfexn7kTrcx
 0z3V+TvQ16YBA==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R3cHx0nJJz6txm;
 Sun, 16 Jul 2023 09:27:56 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <83ttu49vhn.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN> <871qh8o12z.fsf@localhost>
 <83ttu49vhn.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 07:28:09 +0000
Message-ID: <87edl8mi2e.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

>> BTW, is there any particular reason why windows_or_buffers_changed is
>> not a queue of windows/buffer to be re-displayed?
>
> Why do we need such a queue, when the redisplay flags of buffers and
> windows are supposed to tell us that already?

To not loop over all the existing windows and frames in xdisp.c:506
redisplay branch.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 07:36:01 +0000
Resent-Message-ID: <handler.64596.B64596.168949293427443 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168949293427443
          (code B ref 64596); Sun, 16 Jul 2023 07:36:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 07:35:34 +0000
Received: from localhost ([127.0.0.1]:46651 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKwI2-00078Y-Fq
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:35:34 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:43296)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKwI0-00078L-1c
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 03:35:33 -0400
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 <eliz@HIDDEN>)
 id 1qKwHt-0002Fr-UG; Sun, 16 Jul 2023 03:35:25 -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=4H/v7A6ODAPkKJKE7picPeT18VayrG+PHsPtU0DVpMc=; b=ZLkaJqpdbpNU
 4X7ObEBP4F5Y2k0VfmPlSaURlUdQcawcNAUvVh6VNtRPOFtnzeGp6JrAshi0pv5HoFdu/F4jMbGoP
 g0c7Vy3a3mqDSW88tLNoEi/fv8C7e6vT7w1EibKG48Uqt4OqseaMjEt19vXNeM8hbCW2DlaIetSEH
 p6SVS6O0wPcSpr3Xmd2tU82GUZW1c25hyLaawFdBG47gBGsLjqEMaQzf+5lZyaK1R/RBgct3AJGCs
 MMYAyCdlCYiaVfGFPs+G+qIGLXI0Oo35j3dBwDqrWo1+RgODkSwvevgFucQfOUPZPDg/itsEW3DOJ
 M/K6SBKBjDercLHZ0KIPjA==;
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 <eliz@HIDDEN>)
 id 1qKwHt-0002rI-Cf; Sun, 16 Jul 2023 03:35:25 -0400
Date: Sun, 16 Jul 2023 10:35:49 +0300
Message-Id: <83lefg9ulm.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87edl8mi2e.fsf@localhost> (message from Ihor Radchenko on Sun,
 16 Jul 2023 07:28:09 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN> <871qh8o12z.fsf@localhost>
 <83ttu49vhn.fsf@HIDDEN> <87edl8mi2e.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 07:28:09 +0000
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> >> BTW, is there any particular reason why windows_or_buffers_changed is
> >> not a queue of windows/buffer to be re-displayed?
> >
> > Why do we need such a queue, when the redisplay flags of buffers and
> > windows are supposed to tell us that already?
> 
> To not loop over all the existing windows and frames in xdisp.c:506
> redisplay branch.

Someone will have to demonstrate that this is worth our while.
Testing a single boolean flag is not an expensive operation, while
maintaining that queue also takes CPU.  Also, some changes in a window
can affect other windows on the same frame, for example if the window
is resized.

IOW, maybe it's a good idea and maybe it isn't, but it definitely
doesn't affect the most expensive parts of redisplay.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 08:27:02 +0000
Resent-Message-ID: <handler.64596.B64596.1689495981622 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>, Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.1689495981622
          (code B ref 64596); Sun, 16 Jul 2023 08:27:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 08:26:21 +0000
Received: from localhost ([127.0.0.1]:46738 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKx5B-00009x-0e
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:26:21 -0400
Received: from mout.gmx.net ([212.227.15.18]:46401)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1qKx58-00009j-KU
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:26:19 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at;
 s=s31663417; t=1689495967; x=1690100767; i=rudalics@HIDDEN;
 bh=NG4Q5wQ1Y4st5ouzhYjUFCrCZ8m4KoIn6xuGAUZVJT0=;
 h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To;
 b=PQcp3XLGmfoG0W43i0ISTCuhbGiufbNq31oHiQZIQs95owwJPQ8yVqPa0I/W6fdg+nuOYzZ
 x/awZkHZ4Yy7W14gU2cStRjw4az6CeDGo13dQMjD4exc4QdG9ELqVPUnII6tCMVbR2LB+Q0sU
 OTEZ1BWdnrdYSJua4kWPFSRb34Etqdz+1SjRXB0Cjet9XM0FYAmx+Pq6aNGnfgmCd7tVF6wRk
 GQceghkax8sGNGs6mh1B7/AMgI/cl18wnuujbwG/EsDS0VXFwugRIlWiD7RDZi88DqJrzdUY0
 LUpbh8r6EXywEDhsmrgGzt13cKWYw3tLeNSG+OF/0fgXbEnH5i7w==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.1.100] ([212.95.8.133]) by mail.gmx.net (mrgmx005
 [212.227.17.190]) with ESMTPSA (Nemesis) id 1N8ofE-1pqckz2102-015oEI; Sun, 16
 Jul 2023 10:26:07 +0200
Message-ID: <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN>
Date: Sun, 16 Jul 2023 10:26:04 +0200
MIME-Version: 1.0
Content-Language: en-US
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <835y6kbgik.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:HlAGhleFpWj/XO1oMlEI8Pbq23BTMhyShjGAThPDSYVXZze7M7T
 JKgeBFYO98a8MfqWd3ZwKS/3JQ2yuBcvlbvncqEkSAEpabAurVy4+A0N3CEuqSePoBt0iRn
 fqcFi70DjYpVli7MCZ/XrQSd8KzqZ9uSViOlDFxDjxcZ/eWdrZ2J4c7kV6Vy3jSUXkNEHJJ
 i+zmvt48yed1lbjraKTvQ==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:lMYrvFqY/4w=;y8SlwzX4YU87UphBBK3zaY83CXN
 LJJ+tMWe1oq6Eakeg+SbFLt1kMm6WqC1tS32TggQZ9lliDOBHn4bMYqVhuVPlpSPAYGrWwjRw
 iVgxuO49B7qVI4xwWDrrrfATA5n34oGBaA/H9eQVGrbLDVp+P6kTH6/61Z2XWm+jQtjAECy0C
 1abZ9rKFzuSc/cypW8sNqinzyVa881ofuANAgEbyhud0b+JLiiBOEtPxXVjvS8PDD5j6S7u2k
 /Qkyppu/ruvwxSP3ypSX3w6rrFW0Hhh/b3LsqKY3zdv9RnlRDPhjAp7GOGFOZlBuCevRuCo2w
 pUfXusz2tkKg4nmvFXrmrc9rha9SUBAhz/WntYf9x9TwaosQeqT9ap731pB3mw4xUBc8XYwij
 Etnix+tKnhcgE6YTGeks5Xn+SAobyzUdCDAANmAy1mkzIskMlNuB9lu1t84wy9Opah5/SU//b
 GlUmMfqDDjB4qltnesYLLHghBoSbBmdAM+xni3Xwq4avBxMTHwnpxj9yTecTEcz3IU55pnTCU
 DYEcGgTmbmygPNemqgEJzymb+OrlbT0F3Z6Yz1isRHV5lCcS9I3iLhKs2lATS8k/UADXTUTTj
 d+MvKOBba/7zTtS/HDs7IQ1ZQou5NyEdpHXnmjBYL3U6VgEhGH0Wk1TqkFkIfVkFSwGzUGw5S
 flM5yWC7fAKVslMuh8zMMh/kaSo4/agM3kYUrt6a0R4xIQHG8ZmuzK9Q8woDVPXR8DjUTl91z
 RyTCh/yhlVGHQ6rFrCgcD69soF2D9tUFuF2W7EbyIo+u3khJLjqUZflfhLn1Ia4fO117schuh
 rZWyW8rhNAs9A83aKPF+tGUHM/xoimIqe7+0y8HtzgGBrZ3JM/EGjrzwQ5MKh5t3aCLnincsu
 FeP+eVeNR/r5diTsi5/5K1hQwzWqU+wu9pRU1rHjqbgZg+deRNa1IhsYlOQNLeHLkftdyLqmn
 f6lkvw==
X-Spam-Score: -0.7 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -1.7 (-)

 > 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.

 From the POV of window management the situation is simple: When the size
of a window or a decoration changes, it would like to tell redisplay
about it.  But redisplay would have to tell it first which kind of
changes it's able to accept.  For example, I don't even know whether,
when running without window matrices, redisplay is capable of doing
something reasonable with the fact that the border between two adjacent
windows shifted and a third window not affected by that shift can be
spared by redisplay.  So from the POV of window management, redisplay
would have to offer a list of such flags it is able to handle and do
something reasonable about.

As an example: one of the worst things the window code does is saving a
window configuration, reading something from the minibuffer and
restoring the window configuration when done.  In nine out of ten cases
the restored configuration will not have changed and redisplay wouldn't
have to do anything.  Now Fset_window_configuration is awful in the
regard that it deletes all windows on the frame regardless of whether
the configuration changed only to "restore" them later (including that
n_leaf_windows allocation hack to find out which glyph matrices can be
safely freed).  While it is fairly easy to fix that, it's by no means
clear what and how to tell redisplay that some window did change in one
of those rare cases where it did.

Try the following simple scenario which currently breaks redisplay:

(let (config)
   (set-frame-parameter nil 'left-fringe 50)
   (y-or-n-p "?")
   (setq config (current-window-configuration))
   (setq left-fringe-width 0)
   (set-window-buffer nil (window-buffer))
   (y-or-n-p "?")
   (set-window-configuration config))

Here 'set-window-configuration' should be able to tell redisplay that it
should redisplay the window but it should be able to tell that iff the
fringe really changed which is fairly easy to find out.  Once it found
out, which kind of flag would it set?

martin

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 08:41:02 +0000
Resent-Message-ID: <handler.64596.B64596.16894968352136 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16894968352136
          (code B ref 64596); Sun, 16 Jul 2023 08:41:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 08:40:35 +0000
Received: from localhost ([127.0.0.1]:46762 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKxIw-0000YO-US
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:40:35 -0400
Received: from mout02.posteo.de ([185.67.36.66]:55093)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qKxIu-0000Y8-Te
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:40:33 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 634F7240101
 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 10:40:27 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689496827; bh=fqp5oCkRzXe3LTZirCqpGbwUzRg8BAeEvx5UaFstpnY=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=PEGx6OkB7ZIN2hit5cHgN/NhaBlmHxTUDwLaZnAnip80RYsp32F1ETHBLR21I6uck
 I1E/AVRBNUEpIF/FWW6VjjYwp4J+79rbsSyASRBhZDKB/S+WHBCPjUCN5WSyEGKR+j
 uEH6o81IZ0rzm/wtPRKCLNLQCuQt1YQPwabp0BUlTGfpgyRRIN60LYprDeAbLT6UZw
 4MExE8lDMYHwjZ5w/sd/9hYEDGy6WDqr02Luz+bWv04IjOUVeLVd5spbxuA5ErVOwH
 ObnthfmA4moxDFtbm4/olYVStHZmoRNjCEL8K9xeTnOM32WGtdmz5QUl8AkJw1qlrV
 gSW1rhBlfKM2g==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R3dvZ0S74z9rxM;
 Sun, 16 Jul 2023 10:40:25 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN>
 <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN>
Date: Sun, 16 Jul 2023 08:40:38 +0000
Message-ID: <87wmz0i709.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

martin rudalics <rudalics@HIDDEN> writes:

> Here 'set-window-configuration' should be able to tell redisplay that it
> should redisplay the window but it should be able to tell that iff the
> fringe really changed which is fairly easy to find out.  Once it found
> out, which kind of flag would it set?

May someone list all the possible displayed elements Emacs considers?

I think that it might be a good new API to have a single function that
marks things for redisplay. That function will accept arguments
indicating what exactly may need to be redisplayed: CURRENT_TEXT_LINE,
FRINGE, LINE_NUMBERS, CURRENT_BUFFER_TEXT, CURRENT_BUFFER_MODELINES,
ALL_MODELINES, CURRENT_FRAME, etc.

Then, every place where we request redisplay will call that single API
function, while being very explicit what kind of redisplay it has in
mind.

That API function may be implemented in backwards-compatible way - we
can just hide the existing logic inside for now and simplify later
instead of directly manipulating global and local flag variables.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 08:51:01 +0000
Resent-Message-ID: <handler.64596.B64596.16894974073439 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: martin rudalics <rudalics@HIDDEN>
Cc: yantar92@HIDDEN, monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16894974073439
          (code B ref 64596); Sun, 16 Jul 2023 08:51:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 08:50:07 +0000
Received: from localhost ([127.0.0.1]:46772 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKxS7-0000tI-LN
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:50:06 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:34774)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKxS3-0000se-3f
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:50:02 -0400
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 <eliz@HIDDEN>)
 id 1qKxRw-00032Q-7E; Sun, 16 Jul 2023 04:49:52 -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=I56FnZqhEJ0mPPUaC9LV8IAZEAzEDya+cx+ofN+YIEY=; b=hufqSodAiKoK
 5uqyJVvDXwmQEa67zhL1Iesy2T8XgsXzfVGR8wc+1sYnGBKBPKgp7ozTVe2PM1t0EJxBTaD8GKnzC
 58lZEfRXtgufSTWFOYEM1jGy7BtjI1PnNZDJuGzqFITHWuIqj4Ht70ZLh0k/BQmE3C4BGJrXjR8/R
 dfjDhE590XT/9tUBZSJ1u6xMaqv0VjxNO882VSA1eFUhx4rpw42bqKoYJ678hHWb8cvDtvxnzdoN7
 Q+7ZsI1EldbOR3fQGYlNhsYt2/1dAZvCKqU2IWmUofU/4kMofoRhxhmARtxgK1j+SoD2y5apfHv+f
 6VTJhBOivK3tH5WYSI8TCw==;
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 <eliz@HIDDEN>)
 id 1qKxRv-0002Ua-Nm; Sun, 16 Jul 2023 04:49:52 -0400
Date: Sun, 16 Jul 2023 11:50:14 +0300
Message-Id: <83fs5o9r5l.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> (message from
 martin rudalics on Sun, 16 Jul 2023 10:26:04 +0200)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN>
 <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN>
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Date: Sun, 16 Jul 2023 10:26:04 +0200
> Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
> From: martin rudalics <rudalics@HIDDEN>
> 
>  From the POV of window management the situation is simple: When the size
> of a window or a decoration changes, it would like to tell redisplay
> about it.  But redisplay would have to tell it first which kind of
> changes it's able to accept.

I don't think this is required.  The information flow is
unidirectional: the functions which change the windows should tell
what they changed, and redisplay will then decide what that requires.
For example, if some windows changed their dimensions, redisplay would
need to know which dimension changed.

> For example, I don't even know whether, when running without window
> matrices, redisplay is capable of doing something reasonable with
> the fact that the border between two adjacent windows shifted and a
> third window not affected by that shift can be spared by redisplay.

If the third window displays a buffer that didn't change in any way,
then yes, the display engine should be capable of doing the above.  On
TTY frames, the display engine considers the entire frame, so it
should see that the portion corresponding to that third window didn't
change, and refrain from redrawing it.

> As an example: one of the worst things the window code does is saving a
> window configuration, reading something from the minibuffer and
> restoring the window configuration when done.  In nine out of ten cases
> the restored configuration will not have changed and redisplay wouldn't
> have to do anything.  Now Fset_window_configuration is awful in the
> regard that it deletes all windows on the frame regardless of whether
> the configuration changed only to "restore" them later (including that
> n_leaf_windows allocation hack to find out which glyph matrices can be
> safely freed).  While it is fairly easy to fix that, it's by no means
> clear what and how to tell redisplay that some window did change in one
> of those rare cases where it did.

We need to add flags that convey the information about which windows
changed what dimensions.

> (let (config)
>    (set-frame-parameter nil 'left-fringe 50)
>    (y-or-n-p "?")
>    (setq config (current-window-configuration))
>    (setq left-fringe-width 0)
>    (set-window-buffer nil (window-buffer))
>    (y-or-n-p "?")
>    (set-window-configuration config))
> 
> Here 'set-window-configuration' should be able to tell redisplay that it
> should redisplay the window but it should be able to tell that iff the
> fringe really changed which is fairly easy to find out.  Once it found
> out, which kind of flag would it set?

I'm not even sure it must find that out.  It could simply tell
redisplay that the fringe really changed.  The rest is up to the
display engine to decide.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 08:57:02 +0000
Resent-Message-ID: <handler.64596.B64596.16894977684030 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: rudalics@HIDDEN, monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16894977684030
          (code B ref 64596); Sun, 16 Jul 2023 08:57:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 08:56:08 +0000
Received: from localhost ([127.0.0.1]:46782 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKxXz-00012v-Pm
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:56:08 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:43580)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKxXw-00012F-Uo
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 04:56:05 -0400
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 <eliz@HIDDEN>)
 id 1qKxXr-0004lA-0B; Sun, 16 Jul 2023 04:55:59 -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=KP20kCGSPsyvyYusPbNoKJ6elG2vEd4Hdhd4wAHSdY0=; b=nSe7uxcxzH0J
 4EVU2URa1uqxOCK7mwsxIDdmUFnWSki659KXUvEgEkDUSAqg7PJ3TiS8c4wRZ2FtDjlghqomBcWcq
 ILTg3Nz1orIY3333gUOIcw5IyJOmpUUWpnHH2hdjJrOdo7Xr/+W8l3QRemt8tjif1HtHW3eou2x8M
 EVSjte4Irwc1cmm/OrreJ4VlyE1H1yClxqWK0s/BEZHq0XxR7ia/bzpbFzr1VV2LJn07owGfgLM/e
 QVvBwa9w05WhI7R/S+RJoWYg7ITiAqXJmsflfSCe+EzNJX4eoq1of4M6aQDhyAgc6r6trS07AjPxP
 yucz3n7594s1g8gXdTW5EQ==;
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 <eliz@HIDDEN>)
 id 1qKxXq-0003LN-G9; Sun, 16 Jul 2023 04:55:58 -0400
Date: Sun, 16 Jul 2023 11:56:22 +0300
Message-Id: <83edl89qvd.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87wmz0i709.fsf@localhost> (message from Ihor Radchenko on Sun,
 16 Jul 2023 08:40:38 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN>
 <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> <87wmz0i709.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, monnier@HIDDEN,
>  64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 08:40:38 +0000
> 
> martin rudalics <rudalics@HIDDEN> writes:
> 
> > Here 'set-window-configuration' should be able to tell redisplay that it
> > should redisplay the window but it should be able to tell that iff the
> > fringe really changed which is fairly easy to find out.  Once it found
> > out, which kind of flag would it set?
> 
> May someone list all the possible displayed elements Emacs considers?

What do you mean by "display element" here?  The Emacs display engine
already has a term "display element", but I think it means something
very different: character glyphs, images, compositions, etc.  See the
function get_next_display_element in xdisp.c.

So we had better agreed on clear terminology here to avoid terrible
confusion.

> I think that it might be a good new API to have a single function that
> marks things for redisplay. That function will accept arguments
> indicating what exactly may need to be redisplayed: CURRENT_TEXT_LINE,
> FRINGE, LINE_NUMBERS, CURRENT_BUFFER_TEXT, CURRENT_BUFFER_MODELINES,
> ALL_MODELINES, CURRENT_FRAME, etc.

The first step is to identify the changes in which the display engine
is interested, and design the flag(s) to communicate this information
to it.  The actual API, whether a single function or a set of macros
or something else, comes later, and is not a complicated decision to
make.

Please note that whether current text line needs to be redisplayed, or
if line numbers need to be redisplayed, or if mode line needs to be
redisplayed, is in many cases a decision that only the display engine
can make.  So you seem to be thinking in terms that are not entirely
correct.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 09:42:01 +0000
Resent-Message-ID: <handler.64596.B64596.16895004878661 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: rudalics@HIDDEN, monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16895004878661
          (code B ref 64596); Sun, 16 Jul 2023 09:42:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 09:41:27 +0000
Received: from localhost ([127.0.0.1]:46866 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKyFr-0002Fd-3T
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 05:41:27 -0400
Received: from mout02.posteo.de ([185.67.36.66]:47813)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qKyFm-0002FN-JJ
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 05:41:26 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id C7CB0240104
 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 11:41:16 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689500476; bh=eIEW9AucfmzAyH4FD+vcPTUouqKRrZqyQbTMrvIIxD8=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=CEfz+PASrKubirSOW5MEr2VkQOqomc54B+xJy3uPkXHT5aA3gUMOMTiSQZCqigr5I
 D8hxIi5FrHPQTNnDiMbVi6JWiSAdLLwHeFoQKRlgVaBxvK6G6ThYjqRxAy+E03hQdq
 uDw2t+ez1eHyWF96lEsg7yXBrcImFks6llJx0si29HNpsyS/upW0S10PBe2QIQ32Fw
 4yEcNuW+DXlq0TEUft5eMbSv/7G9JytoGdOtKhnnPHZmn50V7wA/TDNwAzr49Y6v80
 bUA+lp2gEOHd5GrFTddoLtuxp1rVEITYCq+SzYxbRTMi8lBvDa4XPgloY9z2zt9t17
 OX3CItQug668Q==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R3gFl6H6yz6tws;
 Sun, 16 Jul 2023 11:41:15 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <83edl89qvd.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN>
 <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> <87wmz0i709.fsf@localhost>
 <83edl89qvd.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 09:41:28 +0000
Message-ID: <87a5vwi46v.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

>> May someone list all the possible displayed elements Emacs considers?
>
> What do you mean by "display element" here?  The Emacs display engine
> already has a term "display element", but I think it means something
> very different: character glyphs, images, compositions, etc.  See the
> function get_next_display_element in xdisp.c.
>
> So we had better agreed on clear terminology here to avoid terrible
> confusion.

Fair point.
The top commentary in xdisp.c defines "display elements" as elements in
glyph matrix. These include characters (possibly composed) and images.

However, not everything drawn in Emacs frame is represented by display
elements :

1. Title bar is not using glyphs at all
2. Same for scroll bars
3. and menu bars
4. and tool bars
5. and window boundaries
6. and things like fill-column-indicator (AFAIU)

Further, some display elements are grouped:
1. per frame
2. per window
3. within fringes
4. within mode-line
5. within buffer text area
6. within a line of text
7. within header line
8. within tab-line

I think that the flags should provide a way to mark each of the groups
or individual glyphs for future redisplay.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 10:30:03 +0000
Resent-Message-ID: <handler.64596.B64596.168950339214063 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: rudalics@HIDDEN, monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168950339214063
          (code B ref 64596); Sun, 16 Jul 2023 10:30:03 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 10:29:52 +0000
Received: from localhost ([127.0.0.1]:46905 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKz0h-0003el-R5
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:29:52 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:58882)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKz0f-0003eW-65
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:29:50 -0400
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 <eliz@HIDDEN>)
 id 1qKz0Z-00006J-6q; Sun, 16 Jul 2023 06:29:43 -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=4XZ7JzybYfweWxXyjFdDs7jNgdX6gAB+JHQnsRMbA/0=; b=inKU80Y0HoED
 AOR4Y4oofXWeJSb4vJlpsaAw4QdGrFLcQB/BBvS29zz3LihXkDNsV7wPQSSJ8NQDngLvU1DnkVJsw
 vRpoNhAAiyD/H5osKQTVc8IpBejgbOdj13jnntjKawZVhT6+ByWhcKsTgiYUCojAmOuQb2DVtK6ir
 jzPA1QTUHyVm8mylkIs+I1x1A8o/tG/ZAp+texoeYbK+uS3eyW1rbhcEZUw5bm49hasc72FU3UXWb
 6NsRHOrk5W9XHVsOQzXiSH4GVb4XvbeVjrMk8hxAbynzvzoG/6HOB7k6itQGAvMuSNqf7w1VOvn+r
 uhf/ogwzUji1+IUVR/GSqQ==;
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 <eliz@HIDDEN>)
 id 1qKz0Y-0004f4-Pd; Sun, 16 Jul 2023 06:29:43 -0400
Date: Sun, 16 Jul 2023 13:30:06 +0300
Message-Id: <835y6k9mj5.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87a5vwi46v.fsf@localhost> (message from Ihor Radchenko on Sun,
 16 Jul 2023 09:41:28 +0000)
References: <877cr4nez9.fsf@localhost> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN>
 <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> <87wmz0i709.fsf@localhost>
 <83edl89qvd.fsf@HIDDEN> <87a5vwi46v.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: rudalics@HIDDEN, monnier@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 09:41:28 +0000
> 
> The top commentary in xdisp.c defines "display elements" as elements in
> glyph matrix. These include characters (possibly composed) and images.

They include more than that, see enum glyph_type in dispextern.h.

> However, not everything drawn in Emacs frame is represented by display
> elements :
> 
> 1. Title bar is not using glyphs at all
> 2. Same for scroll bars

These two are window-system/toolkit widgets.

> 3. and menu bars

This is either a toolkit widget or an Emacs-produced text; in the
latter case it does use our glyphs.

> 4. and tool bars

Depending on whether the tool bar is "external" or not, this could be
a special kind of window with our glyphs.

> 5. and window boundaries

On TTY frames, these are character glyphs.

> 6. and things like fill-column-indicator (AFAIU)

Those are fringe bitmaps, so they belong to the fringe.

> Further, some display elements are grouped:
> 1. per frame
> 2. per window
> 3. within fringes
> 4. within mode-line
> 5. within buffer text area
> 6. within a line of text
> 7. within header line
> 8. within tab-line

The latter 5 are in display-engine realm, and some of them are only
calculated as part of redisplay, so other code should not try to
handle that.  But yes, we definitely need (and already have) buffer
flags, window flags, and frame flags.

> I think that the flags should provide a way to mark each of the groups
> or individual glyphs for future redisplay.

Nothing knows (or should know) about glyphs except the display code.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 10:32:01 +0000
Resent-Message-ID: <handler.64596.B64596.168950348214323 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168950348214323
          (code B ref 64596); Sun, 16 Jul 2023 10:32:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 10:31:22 +0000
Received: from localhost ([127.0.0.1]:46909 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKz2A-0003ix-Cw
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:31:22 -0400
Received: from mout02.posteo.de ([185.67.36.66]:34201)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qKz28-0003il-R7
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:31:21 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 0B52924010E
 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 12:22:26 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689502948; bh=p9FQY8lzZrovUou/MKMGxE/j4PErW9Qvs2VRn4hok1g=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=QOcl0YqeiCltU8gtUf87JaD+ijU+LaP55qhoGFSdNihJPKG24iinBHafPS0/yCvny
 b/q7g8/uMKz22rfjeUDw/BvGQ8geXCECr2Jm2bPPIyUMNSWH7OYn88N5ieSbyXQHMx
 kYeazZT8Q/nu0qk/qa8M8ujjn9n0/Q6V/Q30VJTda93Gz0r93hOe6pLcezRoO/WL/l
 pFN9cXgEkYXRwjwnNTAnNuQIiaOS6xiEcamDgric0SohUWxaf8pYvK3On11K+riXez
 0lgOZHoez1qQSjQl6mDcFSHr5ecJbEfC6cRPkiZWV8HYIhqIitCgF4cB0LawVJlpOx
 Q4ZC4E4IaropQ==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R3h9G0p0hz6txQ;
 Sun, 16 Jul 2023 12:22:25 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
Date: Sun, 16 Jul 2023 10:22:38 +0000
Message-ID: <87ttu4gnpt.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Stefan Monnier <monnier@HIDDEN> writes:

>>   . prevent_redisplay_optimizations_p flag of a buffer
>>   . must_be_updated_p flag of a window
>
> No idea what these mean.
> The name `must_be_updated_p` makes it sound to me like it's redundant
> with the `redisplay` flag above.

I agree about must_be_updated_p. I had exactly same though that it is
redundant with redisplay flag when reading the code.

prevent_redisplay_optimizations_p is intuitively logical, but I still
feel confused because it appears to be redundant upon seeing redisplay
flag in the buffer. It raises a question what redisplay flag really
means - it is causing redisplay of a window/buffer or not necessarily?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 10:38:02 +0000
Resent-Message-ID: <handler.64596.B64596.168950385015160 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168950385015160
          (code B ref 64596); Sun, 16 Jul 2023 10:38:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 10:37:30 +0000
Received: from localhost ([127.0.0.1]:46918 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKz86-0003wR-9H
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:37:30 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:42936)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKz81-0003tL-BM
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:37:28 -0400
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 <eliz@HIDDEN>)
 id 1qKz7v-0002Yz-PX; Sun, 16 Jul 2023 06:37:19 -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=/c8suefAl+Ank3WQNHSMZ4ZQX7JYY6D83wj65abPV1s=; b=cCCk3MySNOcW
 RkL6xiWKry4Tyn9lPEOLgi1S2V6/fhgPs09+x5A3j3ONo86D6UNpQbKklN/zVaUq13PeHlzUQc0yT
 R7agamLxOMT7VnvojB3BRfvVlRFiX/rqANcIfsLyvfjOQqRMinX8thw/8b+A01gfmj3ocfrlJKPk0
 Y+4DR14FEc3aAj3xD1YbLKz9kebWYslDy2c4U0Kz0vUcoKvZJ0cjmWQfKWUevlt3rkEE1le23qwd2
 kY0x+BfkVSLGpTFTxcDTYrydu4NJuyoQX18NG+DBgjZu1E7g9TJdWlV9cjBM7iCvChApNzYbApvSf
 +t2NhRLhK7L0ifLIL58NLQ==;
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 <eliz@HIDDEN>)
 id 1qKz7v-0005UD-8o; Sun, 16 Jul 2023 06:37:19 -0400
Date: Sun, 16 Jul 2023 13:37:42 +0300
Message-Id: <83351o9m6h.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87ttu4gnpt.fsf@localhost> (message from Ihor Radchenko on Sun,
 16 Jul 2023 10:22:38 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 10:22:38 +0000
> 
> Stefan Monnier <monnier@HIDDEN> writes:
> 
> >>   . prevent_redisplay_optimizations_p flag of a buffer
> >>   . must_be_updated_p flag of a window
> >
> > No idea what these mean.
> > The name `must_be_updated_p` makes it sound to me like it's redundant
> > with the `redisplay` flag above.
> 
> I agree about must_be_updated_p. I had exactly same though that it is
> redundant with redisplay flag when reading the code.

Look closer, please.  The name of the flag might suggest what you say,
but its usage suggests otherwise.

> prevent_redisplay_optimizations_p is intuitively logical, but I still
> feel confused because it appears to be redundant upon seeing redisplay
> flag in the buffer. It raises a question what redisplay flag really
> means - it is causing redisplay of a window/buffer or not necessarily?

Neither.

The redisplay flag means that a window or a buffer or a frame need to
be _considered_ for potential redisplay.  (Whether the consideration
will conclude there's a need to actually redraw the corresponding part
of the Emacs display is another matter -- it could conclude that all,
some parts of, or none of the objects marked for redisplay actually
need it.)

prevent_redisplay_optimizations_p says that while considering which
parts of the buffer need to cause redisplay, certain shortcuts and
optimizations designed to make redisplay faster and less expensive
must not be taken/used.

IOW, prevent_redisplay_optimizations_p must come with the redisplay
flag set on the buffer/window/frame, but after that it says a
different thing.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 10:39:01 +0000
Resent-Message-ID: <handler.64596.B64596.168950389015243 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168950389015243
          (code B ref 64596); Sun, 16 Jul 2023 10:39:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 10:38:10 +0000
Received: from localhost ([127.0.0.1]:46923 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKz8j-0003xn-RX
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:38:10 -0400
Received: from mout01.posteo.de ([185.67.36.65]:34991)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qKz8h-0003xK-Oa
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:38:08 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 1D657240029
 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 12:38:02 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689503882; bh=oRqb/lYW5DRVbwkJmrSXETtRXTID110mYg+uag7vra4=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=djY0XaY7lUu0I6879FcRUHG7oiULLSRDEd0E7ZCsDhhexi0koeivnsDNiidZq34Gb
 zyIDNR2/TPhKdGX4ob4KPFQ8FewfP9SuWe82ndlykeRYSlPJi0TlZluO1JiUvBgZK6
 QxPG9m3QM+LTh0+PM5iZW56FNJHjaj0E7yM2J/XC5krtRGDTt9b924AwNJxqSWN5Bp
 PXNq8p/0eJ6iaD84EMBuSrOI4kPVgahhSvonUbIvfJrJhLGGxrTIR7IobCC83i+13i
 J2yEskgkmvLfUO3f1qKfrFZ+Ado//lHepOSDgh/JRT82ue3uZBOIT9gbFBLNhgkztU
 vzds7uPG9a5Tg==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R3hWF3406z6txR;
 Sun, 16 Jul 2023 12:38:01 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <jwvilalayz0.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwvilalayz0.fsf-monnier+emacs@HIDDEN>
Date: Sun, 16 Jul 2023 10:38:14 +0000
Message-ID: <87lefggmzt.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Stefan Monnier <monnier@HIDDEN> writes:

> -/* Non-zero if we should redraw the mode lines on the next redisplay.
> +/* Non-zero if we should redraw the mode line*s* on the next redisplay.
>     Usually set to a unique small integer so we can track the main causes of
> -   full redisplays in `redisplay--mode-lines-cause'.  */
> +   full redisplays in `redisplay--mode-lines-cause'.
> +   Here "mode lines" includes also header-lines and frame names, and
> +   apparently also menu-bars.  The link with header-lines is clear,
> +   but a bit less so for frame names and the menu-bar.  */

It would be even better if *-mode-lines functions were renamed to
something more explicit. It is very disorienting that "mode-line" may
mean actual mode-line, but sometimes more than that.
A clarifying comment is an improvement, but does not make the code in
other places more readable.

Maybe use a term like "info-lines" to avoid confusion of using the same
term for multiple different meanings?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 10:48:01 +0000
Resent-Message-ID: <handler.64596.B64596.168950447416302 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168950447416302
          (code B ref 64596); Sun, 16 Jul 2023 10:48:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 10:47:54 +0000
Received: from localhost ([127.0.0.1]:46932 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKzI9-0004Eq-BI
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:47:53 -0400
Received: from mout02.posteo.de ([185.67.36.66]:44541)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qKzI5-0004Do-A2
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 06:47:51 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id C27CD240101
 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 12:47:43 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689504463; bh=Ixz8djm218elIv7793+a0oUezef6n5X15I5Z1myMekQ=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=KIBkgNexwD7dtgIBFy3w/6wkcaus8s6bbNUUt7cH4xaZzwaXMiQFauWoloq7IwopW
 ySM3icQ5lolIrAl56VFhCCj2BUt55UdykK/UoPcg6yhF0FKUFupA6pxRTLE0TKpTc9
 8FacSeX3qviaxBVT8wxZUNhtdH/tD/dnz7mYo4XC4iK9RrVwOYFbnalkr6b75urSMM
 KC6V3u7tnkUHkc3Iee3WpFPT7TaKCyMAtcTTR8EMJKYrNWZVqT0nXNcLs3uIdlpmBQ
 10pXZMvN1tbMVu5pTLQB+jmOxsvzKkns1rsy7kExbufsmazJXLaV75Tx+euHi8IO7b
 1Npx7rVKIXtZg==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R3hkQ6Bf3z9rxM;
 Sun, 16 Jul 2023 12:47:42 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <83351o9m6h.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost>
 <83351o9m6h.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 10:47:55 +0000
Message-ID: <87ilakgmjo.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

>> I agree about must_be_updated_p. I had exactly same though that it is
>> redundant with redisplay flag when reading the code.
>
> Look closer, please.  The name of the flag might suggest what you say,
> but its usage suggests otherwise.

Do I understand correctly that prevent_display_optimizations_p in
buffer, must_be_updated_p in window, and garbaged in frames all serve
the same purpose of forcing the redisplay?

>> prevent_redisplay_optimizations_p is intuitively logical, but I still
>> feel confused because it appears to be redundant upon seeing redisplay
>> flag in the buffer. It raises a question what redisplay flag really
>> means - it is causing redisplay of a window/buffer or not necessarily?
>
> Neither.
>
> The redisplay flag means that a window or a buffer or a frame need to
> be _considered_ for potential redisplay.  (Whether the consideration
> will conclude there's a need to actually redraw the corresponding part
> of the Emacs display is another matter -- it could conclude that all,
> some parts of, or none of the objects marked for redisplay actually
> need it.)
>
> prevent_redisplay_optimizations_p says that while considering which
> parts of the buffer need to cause redisplay, certain shortcuts and
> optimizations designed to make redisplay faster and less expensive
> must not be taken/used.
>
> IOW, prevent_redisplay_optimizations_p must come with the redisplay
> flag set on the buffer/window/frame, but after that it says a
> different thing.

Then, why not use uniform naming scheme and have the buffer/window/frame
flags names as maybe_redisplay and must_redisplay instead of different
flag name for different object type?

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 11:27:01 +0000
Resent-Message-ID: <handler.64596.B64596.168950679520105 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168950679520105
          (code B ref 64596); Sun, 16 Jul 2023 11:27:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 11:26:35 +0000
Received: from localhost ([127.0.0.1]:46960 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKztb-0005EC-7d
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 07:26:35 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:41298)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKztZ-0005E0-7K
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 07:26:34 -0400
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 <eliz@HIDDEN>)
 id 1qKztS-0001rW-0G; Sun, 16 Jul 2023 07:26:26 -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=aRgN6D2nWkjHJj23Y0f+LZmsQhVSPlZmz5kHjcucsmc=; b=YD+RJU+J9Uvd
 EoAKRZ7gzNyVmUDzP3NbPNfKJKgDpmXQFdPwXPr6/MTBtPilOz3vTN/hSnm2IfmUw6GTsnOUJNmTM
 GsieUGXVivrKwetvDbUFYO0EBvj5nFtgWt5ovXbjkmUBeB6QKDSoJr36c19EWX1mGqXPUSPBN3QIr
 toM5Mps8jor6mNCd20gYrx7Gg0QWY8/3D/0HCHZfQwkAZB+yCDBkJ4aoEX7fv4NYdeJUwGv19L0fb
 yuhdrLBDUcuFwGmpKv4oc2QkiruWpdrUKmqrh7CmgEN9mgs76EbKL0NiI3jiqVUb0EnvRft1zPCby
 yAUbSJmQ5jI86z1VdCVpTQ==;
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 <eliz@HIDDEN>)
 id 1qKztR-0005yk-Fb; Sun, 16 Jul 2023 07:26:25 -0400
Date: Sun, 16 Jul 2023 14:26:48 +0300
Message-Id: <831qh89jwn.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87lefggmzt.fsf@localhost> (message from Ihor Radchenko on Sun,
 16 Jul 2023 10:38:14 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwvilalayz0.fsf-monnier+emacs@HIDDEN> <87lefggmzt.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 10:38:14 +0000
> 
> It would be even better if *-mode-lines functions were renamed to
> something more explicit. It is very disorienting that "mode-line" may
> mean actual mode-line, but sometimes more than that.
> A clarifying comment is an improvement, but does not make the code in
> other places more readable.

If we want to do this, the job is larger yet.  We also have this:

  struct glyph_row
  {
    [...]
    /* True means row is a mode or header/tab-line.  */
    bool_bf mode_line_p : 1;

    /* True means row is a tab-line.  */
    bool_bf tab_line_p : 1;

  struct it
  {
    [...]
    /* True means window has a tab line at its top.  */
    bool_bf tab_line_p : 1;

    /* True means window has a mode line at its top.  */
    bool_bf header_line_p : 1;

  struct glyph_matrix
  {
    [...]
    /* True means window displayed in this matrix has a tab line.  */
    bool_bf tab_line_p : 1;

    /* True means window displayed in this matrix has a header
       line.  */
    bool_bf header_line_p : 1;


and the code which deals with these.  (Note that the bits are
inconsistent between glyph_row and the other two structures, and all
of them mention only 2 out of 3 attributes.)

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 11:32:01 +0000
Resent-Message-ID: <handler.64596.B64596.168950707330350 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168950707330350
          (code B ref 64596); Sun, 16 Jul 2023 11:32:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 11:31:13 +0000
Received: from localhost ([127.0.0.1]:46965 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qKzy4-0007tR-VO
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 07:31:13 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:53806)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qKzy3-0007tC-JA
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 07:31:12 -0400
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 <eliz@HIDDEN>)
 id 1qKzxy-0003Nt-4x; Sun, 16 Jul 2023 07:31:06 -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=XD7I2+GWqW6AuO4HPWsWRGL7GCqUP53erinBlrqEnKw=; b=lmaplxz9PthM
 c4+M1k6ZHSfYEeK2G6/NZO5rEIWqZU+trszZNpW7POsZjhxylJm6gLyhBXNFtBH2NpFdWw1YaWuSi
 V3lP4UgUd2jhG7nz5fjj2VAEsBx+ITzKSNdD9ErnaD32rs3+z29UjKnyRKY7sPzqBRZgBSqCvmL/0
 qStuA41qnl52Cxpet26n1fSjkrxcL/QZwX0oxaHlXK2i+UoH9BdB7IckMOVzyV5Y67bDIl9n6H9uj
 0mRdsZZ4iRS7u/z8Ft5FmdhhIoQEZliVRBghIDH6RiJzXjAP60qnD8XuK7C85o68G7z4whgUYhAVS
 WoeOc255ihbH0QwQFk+Wkw==;
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 <eliz@HIDDEN>)
 id 1qKzxx-0000x9-3L; Sun, 16 Jul 2023 07:31:05 -0400
Date: Sun, 16 Jul 2023 14:31:29 +0300
Message-Id: <83zg3w854e.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87ilakgmjo.fsf@localhost> (message from Ihor Radchenko on Sun,
 16 Jul 2023 10:47:55 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost>
 <83351o9m6h.fsf@HIDDEN> <87ilakgmjo.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 10:47:55 +0000
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> >> I agree about must_be_updated_p. I had exactly same though that it is
> >> redundant with redisplay flag when reading the code.
> >
> > Look closer, please.  The name of the flag might suggest what you say,
> > but its usage suggests otherwise.
> 
> Do I understand correctly that prevent_display_optimizations_p in
> buffer, must_be_updated_p in window, and garbaged in frames all serve
> the same purpose of forcing the redisplay?

They all force redisplay, yes, but in different ways.  For example,
the frame's garbaged flag means the entire frame with all its windows
and decorations might need to be redrawn.  By contrast,
prevent_redisplay_optimizations_p just means "don't use some of the
redisplay optimizations that we otherwise could be tempted to try".
IOW, not redisplaying a window at all is not an "optimization".

> > IOW, prevent_redisplay_optimizations_p must come with the redisplay
> > flag set on the buffer/window/frame, but after that it says a
> > different thing.
> 
> Then, why not use uniform naming scheme and have the buffer/window/frame
> flags names as maybe_redisplay and must_redisplay instead of different
> flag name for different object type?

Historical reasons.  But such naming convention is of secondary
importance, IME.  As long as the names are not completely misleading,
and their effects are well documented, 90% of the job is done.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 14:05:01 +0000
Resent-Message-ID: <handler.64596.B64596.168951628317570 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168951628317570
          (code B ref 64596); Sun, 16 Jul 2023 14:05:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 14:04:43 +0000
Received: from localhost ([127.0.0.1]:48335 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qL2Md-0004ZJ-BQ
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:04:43 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:7479)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qL2MY-0004Yu-Dw
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:04:42 -0400
Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 1D98A442854;
 Sun, 16 Jul 2023 10:04:33 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id D0B7944284E;
 Sun, 16 Jul 2023 10:04:31 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689516271;
 bh=cIaUwIGQOb4vf/MZMp1xcfzso8EDp4gG2HQeNrvU5b0=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=iJ1rQadE3wkhaxVAyU2tKVE9KaPzFhDjfqGmhcVmZaoSiAcRcDFYN6fqhpf8CAHBa
 396o0Tat9lLrgzGIQ8EmwBUqcJJBHHGGGfdwGd4KrG2ucJqePQfXkXKFgRlcihCr8B
 fGYjDfIf64KiaIfKSSdsgnjWnEms+RNy5wLFzmNtqUS7Z026YvmFvldPBvVu1poeum
 MpnjBp+6Zqeg5pzYizO0Oyf71DuVcPF8iftyg2rz5KMP8zdx/B5rzdAuBKkq2Y1tLt
 obM1DNPR0YcTZUdLZ1ALy/0cbN0ECdLMw7ZsOENtWZuQlhZmDkTuXpGhtreA4/EIhL
 xlwqvFSxT0kAQ==
Received: from pastel (unknown [108.175.226.218])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A40501202FC;
 Sun, 16 Jul 2023 10:04:31 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <871qh8o12z.fsf@localhost> (Ihor Radchenko's message of "Sun, 16
 Jul 2023 05:52:04 +0000")
Message-ID: <jwva5vw9cr7.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
 <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
 <83a5vxas9k.fsf@HIDDEN> <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN>
 <871qh8o12z.fsf@localhost>
Date: Sun, 16 Jul 2023 10:04:30 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL -0.159 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> -  /* 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.

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).


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 14:27:01 +0000
Resent-Message-ID: <handler.64596.B64596.168951758520918 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168951758520918
          (code B ref 64596); Sun, 16 Jul 2023 14:27:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 14:26:25 +0000
Received: from localhost ([127.0.0.1]:48366 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qL2hc-0005RK-PB
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:26:25 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:10350)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qL2ha-0005Qy-LN
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:26:23 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 09DB11000C4;
 Sun, 16 Jul 2023 10:26:17 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 14E42100097;
 Sun, 16 Jul 2023 10:26:16 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689517576;
 bh=x7QlzWnSuJyoL9mTQKol6LAvX8C3G5epleB0ubRv3O0=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=N+P+UX9OuqFFXc/neZ05LylixTo3USuchVYxphCXAnC+9QmI+y6kuMi4QarRaOucj
 Dy6FIsPyXS2RtkCgPRkHKwNwinZFY0Sj6stK1pA9g3bIsR5rKROWh+7UtPhXEdpKfG
 KgbAcWw36cmCy6Wn7pCk78SkZOIWrRQMtmKoZcwp+L55YAcswapqX2HQKbrLx07A2N
 5BL63ZJoMGWkKXZt33rAN2LOwPfIgplrL7cesqfyoGfPZxbVrpMOVhIw9phn/NVRZ6
 Ro/fq1gfrF2QfsV4iadxyiwP6nTFoEmvnwPLBYAeKh1YR9NU0PlrB7/zdGiKuz0vC8
 UEJmz2JwCsPvQ==
Received: from pastel (unknown [108.175.226.218])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id DD63612030C;
 Sun, 16 Jul 2023 10:26:15 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <87ilakgmjo.fsf@localhost> (Ihor Radchenko's message of "Sun, 16
 Jul 2023 10:47:55 +0000")
Message-ID: <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
 <87ilakgmjo.fsf@localhost>
Date: Sun, 16 Jul 2023 10:26:10 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.260 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>>> I agree about must_be_updated_p. I had exactly same though that it is
>>> redundant with redisplay flag when reading the code.
>> Look closer, please.  The name of the flag might suggest what you say,
>> but its usage suggests otherwise.
> Do I understand correctly that prevent_display_optimizations_p in
> buffer, must_be_updated_p in window, and garbaged in frames all serve
> the same purpose of forcing the redisplay?

My understanding of the redisplay code is that it's split into 3 part:

1- decide which windows may need to be updated.
2- update the glyph matrix of a window.
3- update the glass by comparing the old glyph matrix and the new one.

[ The point between 1 and 2 is made visible to ELisp via
  `pre-redisplay-function`.  ]

The `redisplay` bits belong to step (1).
The `prevent_display_optimizations_p` OTOH belong to step 2, AFAIU.

BTW, I wish those 3 steps were exposed to ELisp, so the top-level of
redisplay could be moved to ELisp.  This would allow for example
`follow-mode` to pick a more appropriate order in which to process the
windows at step 2.

> Then, why not use uniform naming scheme and have the buffer/window/frame
> flags names as maybe_redisplay and must_redisplay instead of different
> flag name for different object type?

For that someone first needs to have a clear idea of what these things
do and how they relate to each other :-)


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 14:28:02 +0000
Resent-Message-ID: <handler.64596.B64596.168951764921083 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168951764921083
          (code B ref 64596); Sun, 16 Jul 2023 14:28:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 14:27:29 +0000
Received: from localhost ([127.0.0.1]:48371 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qL2if-0005Tz-8e
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:27:29 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:50336)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qL2ia-0005Td-Hj
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:27:28 -0400
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 <eliz@HIDDEN>)
 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==;
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 <eliz@HIDDEN>)
 id 1qL2iU-0001ku-CR; Sun, 16 Jul 2023 10:27:18 -0400
Date: Sun, 16 Jul 2023 17:27:41 +0300
Message-Id: <83r0p87wyq.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwva5vw9cr7.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sun, 16 Jul 2023 10:04:30 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
 <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
 <83a5vxas9k.fsf@HIDDEN> <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN>
 <871qh8o12z.fsf@localhost> <jwva5vw9cr7.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>,  64596 <at> 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.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 14:46:01 +0000
Resent-Message-ID: <handler.64596.B64596.168951870823701 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168951870823701
          (code B ref 64596); Sun, 16 Jul 2023 14:46:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 14:45:08 +0000
Received: from localhost ([127.0.0.1]:48388 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qL2zj-0006AC-C4
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:45:07 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:47770)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qL2zd-000697-H4
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:45:05 -0400
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 <eliz@HIDDEN>)
 id 1qL2zX-000246-Nd; Sun, 16 Jul 2023 10:44:55 -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=pd4R7tzzZSS21bj49fhQEZKAPOowKqkM3xEFVdU+QvA=; b=lR07At887/+T
 0Z+wNfeq5Rs7I8sGKTHyKKZcfTVJJ6BHNeqrwFMlzuKlCqS2IP2Q/2D9za4Lu9f2bPUP8ndQOAKv1
 9zZLv4JYc13jZ5aRqyJdmbtl5QBRA4QsEssySPPVBmfBqDEmoFJCsd/Sc6/kzQE7YYDq2z2SdNhkf
 asf9Up2FXh1kJ7yUkUj6MSC5bzkVrXSL+X/7zpMKvUBAeizxx3jhH3iVzRVEmlG5abBUogi/tICal
 otUzeHgaSRvHn49VrXaczLCECIWuZnH4dTboR/X/yYLG4pn3hrSBWaCMpysXDb8zD2Bf2TUx0e+1p
 TiCtUl2iMVJ5JC29VLtlwg==;
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 <eliz@HIDDEN>)
 id 1qL2zX-0005GB-8P; Sun, 16 Jul 2023 10:44:55 -0400
Date: Sun, 16 Jul 2023 17:45:18 +0300
Message-Id: <83pm4r9apt.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sun, 16 Jul 2023 10:26:10 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
 <87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>,  64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 10:26:10 -0400
> 
> My understanding of the redisplay code is that it's split into 3 part:
> 
> 1- decide which windows may need to be updated.

More accurately:

  1a - decide whether all the windows need to be considered, or just
       the selected window
  1b - if all the windows need to be considered, decide for each frame
       whether it needs to be considered, and if so, consider all of
       that frame's windows

Considering a window can sometimes decide very quickly that the window
doesn't need to be redisplayed, but, as I mentioned elsewhere, when
its frame's redisplay flag is set, we never decide that, and the
frame's redisplay flag is what causes us to consider a frame in the
first place.

> 2- update the glyph matrix of a window.

This update can be partial -- that's one of the redisplay
optimizations.  That is, we update only a very small part of the glyph
matrix, as small as a single glyph row (= screen line).

> 3- update the glass by comparing the old glyph matrix and the new one.
> 
> [ The point between 1 and 2 is made visible to ELisp via
>   `pre-redisplay-function`.  ]
> 
> The `redisplay` bits belong to step (1).
> The `prevent_display_optimizations_p` OTOH belong to step 2, AFAIU.

Yes.

> BTW, I wish those 3 steps were exposed to ELisp, so the top-level of
> redisplay could be moved to ELisp.  This would allow for example
> `follow-mode` to pick a more appropriate order in which to process the
> windows at step 2.

follow-mode needs much more than that.  But if you want to be able to
tell redisplay "update only this window and nothing else", I think it
should be easy to accomplish by adding a single function and no other
changes: all you need is to call 'redisplay' (which is already
exposed) after setting the redisplay flag of a single window.

> > Then, why not use uniform naming scheme and have the buffer/window/frame
> > flags names as maybe_redisplay and must_redisplay instead of different
> > flag name for different object type?
> 
> For that someone first needs to have a clear idea of what these things
> do and how they relate to each other :-)

Right.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 14:50:02 +0000
Resent-Message-ID: <handler.64596.B64596.168951896524585 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168951896524585
          (code B ref 64596); Sun, 16 Jul 2023 14:50:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 14:49:25 +0000
Received: from localhost ([127.0.0.1]:48393 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qL33t-0006OT-8G
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:49:25 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:13241)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qL33r-0006OA-V0
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 10:49:24 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 4B22B1000C4;
 Sun, 16 Jul 2023 10:49:18 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 5FCF5100097;
 Sun, 16 Jul 2023 10:49:17 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689518957;
 bh=R3zygOJtMTDta3gIdysw7HG/GMQZoYAWGI9Y4wq0QV8=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=JFmxJucESAm6mZGDUQ6Q2xKCQ67Fcp2OYP1LjbAkLYrsyFJYixXhCiz3Yi0IPLnrt
 KH3gVuFz9jYwdMK9CKox+OO+7LsLC7FyJ1b7Uzv+U8pbfUbuFN7bidcJc0B/JXGoEw
 EpTMton2OVNJ2SnO/6dWlUE2NzcSdIfEXI/cpT/rO1exWpVzkGs1chzXc2RRtkCjoq
 3pGgcCtAsX6aAXDvyXmg6m7LUqlwY36FUTvKSBob/NLS9q+jj2bOASZgAKFAZr2umU
 VpWrcNaoskQGfPp0VcT277Y0xXBI+HOK/Wy7zt7q4ot584JKvs1u5yEiWDO2jzKccN
 YIljMB3JPXvJQ==
Received: from pastel (unknown [108.175.226.218])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 321451202E0;
 Sun, 16 Jul 2023 10:49:17 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83r0p87wyq.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 16 Jul
 2023 17:27:41 +0300")
Message-ID: <jwvy1jf9aww.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <83r0p9b3om.fsf@HIDDEN> <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN>
 <83jzv1b152.fsf@HIDDEN> <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN>
 <83a5vxas9k.fsf@HIDDEN> <jwvwmz0aj9z.fsf-monnier+emacs@HIDDEN>
 <871qh8o12z.fsf@localhost> <jwva5vw9cr7.fsf-monnier+emacs@HIDDEN>
 <83r0p87wyq.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 10:49:16 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.228 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> 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?

Indeed, the frame's `redisplay` bit means "*all* windows in that frame
need to be redisplayed", so it should be set with care.  But since the
code before that only had a single boolean for "redisplay all windows on
all frames", I was often happy enough to replace the global redisplay with
`fset_redisplay` even though it might be possible to be more specific.

`fset_redisplay` is typically used when windows are added/deleted/resized,
because it's hard at that point to know which windows really need to
be updated.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 16:45:01 +0000
Resent-Message-ID: <handler.64596.B64596.16895258583880 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16895258583880
          (code B ref 64596); Sun, 16 Jul 2023 16:45:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 16:44:18 +0000
Received: from localhost ([127.0.0.1]:48445 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qL4r4-00010W-2X
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 12:44:18 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63451)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qL4r2-00010G-03
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 12:44:16 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id ADC54805BA;
 Sun, 16 Jul 2023 12:44:10 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 61EFC8044C;
 Sun, 16 Jul 2023 12:44:09 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689525849;
 bh=PyVCZqLJQk5HeInVemtP2RyftT+JSA1sBmBQ2a1Rz8M=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=NdDqaZWctgu3w6R5RjtunIGfT65LLDhN8lPJfZToA9gXaweOSfQnCwdX+koVgl7N7
 T/u0ZGdkGgAJjgXhUk2X4MtTGvnkEBMlnupv1et30YwJDmGPpFnDF05GtP/1W3JHxE
 RYgtI2I9SLI9DJLnXOwZkfuEDAzYNVlm7snz1/dKQCMAyzphgZ9p9ivAAQ1JmlcS7Q
 On0UEYj/X9tsuEdIhgeLGgCeJIZMfx6yrIOi37dtaDSEZ/gCx8JooKl5o6GzGw8/jx
 Jh8DwdPwQ+Xd1otReW7CLDmP6QSgAUJq2l+I97LsMxQikT4eIH4yfAKpr1cxAGF6kh
 ow6oeE4T5Wdeg==
Received: from pastel (unknown [108.175.226.218])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3B21C1202B9;
 Sun, 16 Jul 2023 12:44:09 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83pm4r9apt.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 16 Jul
 2023 17:45:18 +0300")
Message-ID: <jwvsf9n969o.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
 <87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
 <83pm4r9apt.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 12:44:08 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.050 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> 1- decide which windows may need to be updated.
>
> More accurately:
>
>   1a - decide whether all the windows need to be considered, or just
>        the selected window
>   1b - if all the windows need to be considered, decide for each frame
>        whether it needs to be considered, and if so, consider all of
>        that frame's windows
>
> Considering a window can sometimes decide very quickly that the window
> doesn't need to be redisplayed, but, as I mentioned elsewhere, when
> its frame's redisplay flag is set, we never decide that, and the
> frame's redisplay flag is what causes us to consider a frame in the
> first place.

Hmm... I'm not sure why you're saying

    frame's redisplay flag is what causes us to consider a frame in the
    first place.

AFAICT the main place where we check a frame's `redisplay` bit is in
`needs_no_redisplay` which operates on a window.

In most cases a frame's `redisplay` bit should not be set, tho some of
its windows' `redisplay` bits may be set, and we will consider this
frame and all its windows (to find those that need to be updated).

>> BTW, I wish those 3 steps were exposed to ELisp, so the top-level of
>> redisplay could be moved to ELisp.  This would allow for example
>> `follow-mode` to pick a more appropriate order in which to process the
>> windows at step 2.
>
> follow-mode needs much more than that.

If the redisplay toplevel could be hacked in ELisp, follow-mode could
call the `update-window-glyph-matrix` on the "main window" of its
window-set first, then get the resulting window-end/start and use that
to adjust/scroll its next/prev windows, and then call
`update-window-glyph-matrix` on them, thus propagating the information
in the right direction and avoiding unnecessary redisplay computations.

> But if you want to be able to tell redisplay "update only this window
> and nothing else", I think it should be easy to accomplish by adding
> a single function and no other changes: all you need is to call
> 'redisplay' (which is already exposed) after setting the redisplay
> flag of a single window.

That won't avoid redisplaying the other windows whose `redisplay` bits
had been set already for other reasons.

I guess we could try to "save the redisplay bit" of other
windows/buffers/frames, and restore them afterwards.  Also, it would be
good to be able to compute the glyph matrices of the various affected
windows before we do the actual glass update (especially if we want to
handle iteration where some part of the redisplay (e.g. jit-lock,
evaluation of mode-lines and menu bars, point moving out of scope
forcing a scroll, you name it) causes changes which require
recomputing a glyph matrix we just computed).


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 17:12:02 +0000
Resent-Message-ID: <handler.64596.B64596.168952748516775 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168952748516775
          (code B ref 64596); Sun, 16 Jul 2023 17:12:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 17:11:25 +0000
Received: from localhost ([127.0.0.1]:48483 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qL5HJ-0004MU-AW
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 13:11:25 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:40052)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qL5HF-0004MF-MC
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 13:11:23 -0400
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 <eliz@HIDDEN>)
 id 1qL5H9-0003B1-6V; Sun, 16 Jul 2023 13:11:15 -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=za777tUu9XN7z6MU2nJrtc+W3AqV2/F/R3aG40buUGQ=; b=huFp+H8EDyJt
 rGxjChgH8H994kDldky5ktzJSBHmmJD+qZNLbMQP3fWYUghcrWqkGr2BUU6nOXqSN5smO0UY6HGM8
 l4TuJHwNaQwgX3Ck2IRrR6xi99nRhT81VhAhg+t2gmYHP6UtCwHnOJDy16n96RlhcjhMspmM94WWM
 VcImLc+X/s6we6t1FYOtqNS8A3NoKjjkbgtLGYrI7Cr3o8WfS1ygOCorI+8cChA8Ic3SbaRHMdrLk
 W4lu7luXoES/OU45O5FYKem1h283xa+dLiZbLuw17V2IyDwfpap2SQOdRnWQ1YVG7tgL3GTRfbg5d
 fxgd5/PO5IpeeopaSpczhg==;
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 <eliz@HIDDEN>)
 id 1qL5Gu-0006Jt-Ju; Sun, 16 Jul 2023 13:11:14 -0400
Date: Sun, 16 Jul 2023 20:11:24 +0300
Message-Id: <83mszv93yb.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvsf9n969o.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sun, 16 Jul 2023 12:44:08 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
 <87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
 <83pm4r9apt.fsf@HIDDEN> <jwvsf9n969o.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 12:44:08 -0400
> 
> >   1a - decide whether all the windows need to be considered, or just
> >        the selected window
> >   1b - if all the windows need to be considered, decide for each frame
> >        whether it needs to be considered, and if so, consider all of
> >        that frame's windows
> >
> > Considering a window can sometimes decide very quickly that the window
> > doesn't need to be redisplayed, but, as I mentioned elsewhere, when
> > its frame's redisplay flag is set, we never decide that, and the
> > frame's redisplay flag is what causes us to consider a frame in the
> > first place.
> 
> Hmm... I'm not sure why you're saying
> 
>     frame's redisplay flag is what causes us to consider a frame in the
>     first place.

Because fset_redisplay does this:

  void
  fset_redisplay (struct frame *f)
  {
    redisplay_other_windows ();
    f->redisplay = true;
  }

and redisplay_other_windows sets windows_or_buffers_changed, which
then causes consider_all_windows_p to be true upon the next redisplay
cycle:

  consider_all_windows_p = (update_mode_lines
			    || windows_or_buffers_changed);

> If the redisplay toplevel could be hacked in ELisp, follow-mode could
> call the `update-window-glyph-matrix` on the "main window" of its
> window-set first, then get the resulting window-end/start and use that
> to adjust/scroll its next/prev windows, and then call
> `update-window-glyph-matrix` on them, thus propagating the information
> in the right direction and avoiding unnecessary redisplay computations.
> 
> > But if you want to be able to tell redisplay "update only this window
> > and nothing else", I think it should be easy to accomplish by adding
> > a single function and no other changes: all you need is to call
> > 'redisplay' (which is already exposed) after setting the redisplay
> > flag of a single window.
> 
> That won't avoid redisplaying the other windows whose `redisplay` bits
> had been set already for other reasons.

Yes, it will: when a window is redisplayed by redisplay_window, its
redisplay flag is reset, and it will not be redisplayed during this
cycle.  So if you have a way to redisplay a single window, you can do
that in any order you want, one window at a time, and those windows
which you redisplayed in this way will not be redisplayed until the
next cycle.

As for update-window-glyph-matrix, I don't see why that would help,
because updating the matrix without calling update_window fairly soon
after that will not produce the effect that you want.

> I guess we could try to "save the redisplay bit" of other
> windows/buffers/frames, and restore them afterwards.

What for?

> Also, it would be good to be able to compute the glyph matrices of
> the various affected windows before we do the actual glass update
> (especially if we want to handle iteration where some part of the
> redisplay (e.g. jit-lock, evaluation of mode-lines and menu bars,
> point moving out of scope forcing a scroll, you name it) causes
> changes which require recomputing a glyph matrix we just computed).

Sounds like an unnecessary complication to me, and for some situations
I'm not even sure how you can handle them, unless you thoroughly
redesign the display code.

IOW, this is not just a matter of exposing a small number of functions
to Lisp, IMO.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 17:20:01 +0000
Resent-Message-ID: <handler.64596.B64596.168952798817588 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: monnier@HIDDEN
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168952798817588
          (code B ref 64596); Sun, 16 Jul 2023 17:20:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 17:19:48 +0000
Received: from localhost ([127.0.0.1]:48499 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qL5PP-0004Zb-VD
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 13:19:48 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:47414)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qL5PO-0004ZQ-FY
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 13:19:47 -0400
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 <eliz@HIDDEN>)
 id 1qL5PI-0005iD-5m; Sun, 16 Jul 2023 13:19:40 -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=KtZevbWlsK+q6I7ulIyHKFSkqEt2YBqr7Y56Ri447lQ=; b=e+1iQYrMPRnR
 eP1HhifGDrWb4mhwWKowKL5zCzFLvQzo032Iqb4yJv7dILjkIw4wsctUxjnS7PcUQAtEVHMX7HALX
 1QrmXQ2wxitlwpRTEMFZi8ulSgGAotg2ocSatZk5y1DgDJdUkUUI7RFPKKY8q/zXZQQ96f7NPLWq8
 S91Fr6lxDUquLOPe18T95fsMo0hkvWTHXC7pk0nx1V+tT1kbadlUlxI0EbI1TuXoMakYXI1bY4iKX
 8+n2QOj8disxcfwlf721nd+dUxpgzdVVwX4FoWuahYFfFtQLOCye6oNAMHxKblAOJ98IndCo2OLo7
 2iuJDm9sXKZwSeU3D5Fi5g==;
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 <eliz@HIDDEN>)
 id 1qL5PH-000764-HY; Sun, 16 Jul 2023 13:19:39 -0400
Date: Sun, 16 Jul 2023 20:20:04 +0300
Message-Id: <83ilaj93jv.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <83mszv93yb.fsf@HIDDEN> (message from Eli Zaretskii on Sun, 16
 Jul 2023 20:11:24 +0300)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
 <87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
 <83pm4r9apt.fsf@HIDDEN> <jwvsf9n969o.fsf-monnier+emacs@HIDDEN>
 <83mszv93yb.fsf@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 20:11:24 +0300
> From: Eli Zaretskii <eliz@HIDDEN>
> 
> > > But if you want to be able to tell redisplay "update only this window
> > > and nothing else", I think it should be easy to accomplish by adding
> > > a single function and no other changes: all you need is to call
> > > 'redisplay' (which is already exposed) after setting the redisplay
> > > flag of a single window.

Another easy-to-implement idea: give redisplay_internal a list of
windows in the order you want them redisplayed, in which case it will
follow that order instead of the current depth-first order implemented
by redisplay_windows.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 18:54:01 +0000
Resent-Message-ID: <handler.64596.B64596.16895335935355 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16895335935355
          (code B ref 64596); Sun, 16 Jul 2023 18:54:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 18:53:13 +0000
Received: from localhost ([127.0.0.1]:48578 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qL6ro-0001OJ-TD
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 14:53:13 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:54614)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qL6rm-0001O5-J6
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 14:53:11 -0400
Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 10EAC803B1;
 Sun, 16 Jul 2023 14:53:05 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id EBAA780057;
 Sun, 16 Jul 2023 14:53:03 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689533584;
 bh=yKmtTpMO3CJ5SfUn6QmpjwHQQ7wevZzWwIvBpf2mSj8=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=agMPKG4pnAGYaEa3CaNxGjA05GRAXxVdNNmX0NfRaASlBd47a2a9naXL1t4SZMnbu
 efrwl99hbFFxVb3K13lnKI2M6u+fbOJCV0NaEpPvH5hKKxv1kPCcdpznj/Zz+abrBY
 FGvQ1NoUbJnBj/InDfg5NjIbpRVA92NKvIz+F8eR1RymB/a+yKDDxjkl8ijU9Rjowm
 XMNMvkBLRHY1FS08vOMVo/6K/BWqGLZWqbAzyPkQq8iVRdlvMnLm76iiyvelNNy82r
 AaRo8oM41zwxeE79Ur+cL61p+8vSoYjwCGb9I3PWPj2TJfyZIbzkANDkdPxv1RV6Q3
 h4Y/ZuJtTEmOw==
Received: from pastel (unknown [108.175.226.218])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id BF59D12031C;
 Sun, 16 Jul 2023 14:53:03 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83mszv93yb.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 16 Jul
 2023 20:11:24 +0300")
Message-ID: <jwvfs5n8ztc.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
 <87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
 <83pm4r9apt.fsf@HIDDEN> <jwvsf9n969o.fsf-monnier+emacs@HIDDEN>
 <83mszv93yb.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 14:53:03 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.042 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

>> Hmm... I'm not sure why you're saying
>> 
>>     frame's redisplay flag is what causes us to consider a frame in the
>>     first place.
>
> Because fset_redisplay does this:
>
>   void
>   fset_redisplay (struct frame *f)
>   {
>     redisplay_other_windows ();
>     f->redisplay = true;
>   }
>
> and redisplay_other_windows sets windows_or_buffers_changed, which
> then causes consider_all_windows_p to be true upon the next redisplay
> cycle:
>
>   consider_all_windows_p = (update_mode_lines
> 			    || windows_or_buffers_changed);

Yes, most calls to `[fbw]set_redisplay` will call
`redisplay_other_windows` and once that function has been called, all
the frames will be "considered", but that happens regardless of the
`redisplay` bit of any particular frame.

The `redisplay` bit is consulted later, once we loop over all the
windows in all those frames, where we decide which of those windows are
updated depending on the `redisplay` bits of the window, the window's
buffer, and the window's frame.

Are you maybe confused by the name of the `FRAME_REDISPLAY_P` macro,
which does *not* pay attention to the `redisplay` bit?

> IOW, this is not just a matter of exposing a small number of functions
> to Lisp, IMO.

I'm sorry if I made you think I suggested it would be a simple matter.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 19:07:01 +0000
Resent-Message-ID: <handler.64596.B64596.16895344036604 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16895344036604
          (code B ref 64596); Sun, 16 Jul 2023 19:07:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 19:06:43 +0000
Received: from localhost ([127.0.0.1]:48598 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qL74p-0001iP-D8
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 15:06:42 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:60312)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qL74h-0001i6-5J
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 15:06:38 -0400
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 <eliz@HIDDEN>)
 id 1qL74b-0001Ww-MP; Sun, 16 Jul 2023 15:06:25 -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=PDbHjc83tXtd0LmMg9fxHlVZNtO7C9e5wfc8zIY9Bi8=; b=buZBFE152KOQ
 MfOiB6RMhpjOX+/viveExuo3YPKP7HzOscytqa19xrjvEj+Imv0HXWrh8DovH6tS0lYljFq3hapVo
 gmmSsvVpsGLhZ6hXWN3w6YL0MeM/uhbYpELUmvXfANBGMV3hKgdwpDHR9HQCax3nwhbpTyWNmGmO8
 itEry8skle7Dh/GEejEA/wVhVZY8GTspPuCjysWxDRralX8ZyvYFdZa4nHZd1HvDbzmQRGsDpoT9Q
 3iqC3esTIC/kASbQhK4NWKoHdV8l5W63xZuLC1rmc/pnQE9RSxL4ofFlt8+OZ/30Co0RWHUwBasyj
 0BXiFi5cZ71eDFMty6Y/PQ==;
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 <eliz@HIDDEN>)
 id 1qL74b-0003tk-6f; Sun, 16 Jul 2023 15:06:25 -0400
Date: Sun, 16 Jul 2023 22:06:49 +0300
Message-Id: <83edl78yly.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwvfs5n8ztc.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sun, 16 Jul 2023 14:53:03 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
 <87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
 <83pm4r9apt.fsf@HIDDEN> <jwvsf9n969o.fsf-monnier+emacs@HIDDEN>
 <83mszv93yb.fsf@HIDDEN> <jwvfs5n8ztc.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -0.0 (/)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 14:53:03 -0400
> 
> >> Hmm... I'm not sure why you're saying
> >> 
> >>     frame's redisplay flag is what causes us to consider a frame in the
> >>     first place.
> >
> > Because fset_redisplay does this:
> >
> >   void
> >   fset_redisplay (struct frame *f)
> >   {
> >     redisplay_other_windows ();
> >     f->redisplay = true;
> >   }
> >
> > and redisplay_other_windows sets windows_or_buffers_changed, which
> > then causes consider_all_windows_p to be true upon the next redisplay
> > cycle:
> >
> >   consider_all_windows_p = (update_mode_lines
> > 			    || windows_or_buffers_changed);
> 
> Yes, most calls to `[fbw]set_redisplay` will call
> `redisplay_other_windows` and once that function has been called, all
> the frames will be "considered", but that happens regardless of the
> `redisplay` bit of any particular frame.

If we always set these flags by calling these functions, then we will
end up doing more in redisplay than needed, because update_mode_lines
and windows_or_buffers_changed also disable certain optimizations.
When someone writes code that calls fset_redisplay, he or she are
likely to think that all this does is set the redisplay flag.  Which
is not true.  If every call to fset_redisplay indeed needs to disable
those optimizations, we should have more flags, and should probably
not call the function fset_redisplay, but something else.

> The `redisplay` bit is consulted later, once we loop over all the
> windows in all those frames, where we decide which of those windows are
> updated depending on the `redisplay` bits of the window, the window's
> buffer, and the window's frame.

That's not all of the uses of this flag.  Here's one example of other
uses:

	  if (some_windows
	      && !f->redisplay
	      && !w->redisplay
	      && !XBUFFER (w->contents)->text->redisplay)
	    continue;

(This avoids updating the tool bar and the tab bar of the frame, and
there's a similar condition that avoids updating the frame's title.)

> Are you maybe confused by the name of the `FRAME_REDISPLAY_P` macro,
> which does *not* pay attention to the `redisplay` bit?

No, I don't think I'm confused about that.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 19:27:01 +0000
Resent-Message-ID: <handler.64596.B64596.16895356118321 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16895356118321
          (code B ref 64596); Sun, 16 Jul 2023 19:27:01 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 19:26:51 +0000
Received: from localhost ([127.0.0.1]:48603 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qL7ON-0002A9-Hh
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 15:26:51 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:47730)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qL7OL-00029v-07
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 15:26:50 -0400
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 <eliz@HIDDEN>)
 id 1qL7OE-00080D-5u; Sun, 16 Jul 2023 15:26:42 -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=AMtrYx7FMM516/INED63gKFEJuadvCVYYU2J9xCwfbc=; b=cMDxVrWvCdMI
 IS278VNvaxh7d53lyO4tYECNVxcZG6TwZ/KR41b366PyB7QLzWZ+E1yPPcULL5TS6/dKYHt8y2C1W
 7R1jHiBiGNT4bn9ugsjY7RILgVzJILuZok2sMnSXDuzYJJSjpKikiqR3HpcZtxR4ZisQ+HYYRsbKS
 xUPMiZ07I6MNmoJAc07JTXLkWjDq+WwOMncKZnPoa7E6ffd5etp58ofFCVYEM6uj6TJ7wtooI0Zgf
 pnblst+JkbqpeMlbZsGXoY3Gn4vOCJQr8bEpajSi8oZDr9KLz/BluBeiGGPPPpvhlqmqeJKGLz5sq
 ydSunfFkRaVGp5QVkRYGkA==;
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 <eliz@HIDDEN>)
 id 1qL7OD-000690-MG; Sun, 16 Jul 2023 15:26:41 -0400
Date: Sun, 16 Jul 2023 22:27:06 +0300
Message-Id: <83bkgb8xo5.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87ttu4gnpt.fsf@localhost> (message from Ihor Radchenko on Sun,
 16 Jul 2023 10:22:38 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 10:22:38 +0000
> 
> Stefan Monnier <monnier@HIDDEN> writes:
> 
> >>   . prevent_redisplay_optimizations_p flag of a buffer
> >>   . must_be_updated_p flag of a window
> >
> > No idea what these mean.
> > The name `must_be_updated_p` makes it sound to me like it's redundant
> > with the `redisplay` flag above.
> 
> I agree about must_be_updated_p. I had exactly same though that it is
> redundant with redisplay flag when reading the code.

Actually, the must_be_updated_p flag is not for xdisp.c, i.e. not for
redisplay_window and its subroutines.  It is for update_window, which
is the last, 3rd, stage of a redisplay cycle, most of the code of
which is in dispnew.c.  That's where the newly computed glyph matrix
of a window is compared to its current matrix, and Emacs decides what,
if anything, should be actually written to the glass.  What happens
with this flag is that redisplay_window and friends _set_ this flag
for windows that dispnew.c _must_ update.  The flag is tested in
dispnew.c, see there for its use and comments.

So it was wrong for me to include that flag in the list which started
this sub-thread.  Sorry about that.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 20:13:02 +0000
Resent-Message-ID: <handler.64596.B64596.168953835512882 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168953835512882
          (code B ref 64596); Sun, 16 Jul 2023 20:13:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 20:12:35 +0000
Received: from localhost ([127.0.0.1]:48636 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qL86c-0003Li-TQ
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 16:12:35 -0400
Received: from mout02.posteo.de ([185.67.36.66]:52787)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qL86Z-0003LQ-HW
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 16:12:33 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id 60346240103
 for <64596 <at> debbugs.gnu.org>; Sun, 16 Jul 2023 22:12:25 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689538345; bh=sW3T6KA74iidfobHcIckChVUfHvLqjpWpeGbPxHrZd4=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=RDq7RhXp4wzVnmw/TEFcpSNBEcnFmpN4Mz+pMP7KgJUOqdEi9TmCsKFhPG/NHqA8f
 +gFu2YnKw7/NnpYG1vG5E1RT3aBkVXUk6K5SNrTIhoI5O0ber8lnjGPu7zeAAAm0B+
 pxY19h0awc2w+KYkHSaHsQsOa20bTVU2FM9RbFWAvhtlInlSINqSL7Q2g/EVhNZnVT
 fFhyaX7SIWLM5LSLvGuKQvWi4eAJ/Jwt4EXhWVWm/KF9jh9ICkkdmJxht9PQHr6Coj
 7E925nR5r/lbJMKnTWsNWB/KXfJ6o9E/eyjcjexlAVrJXyGj6Uwp6o9vSEMZtDeGkO
 npz1rnlqetYVw==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R3xG043c2z9rxL;
 Sun, 16 Jul 2023 22:12:24 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <83bkgb8xo5.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost>
 <83bkgb8xo5.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 20:12:34 +0000
Message-ID: <87jzuz1uq5.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

>> From: Ihor Radchenko <yantar92@HIDDEN>
>> Cc: Eli Zaretskii <eliz@HIDDEN>, 64596 <at> debbugs.gnu.org
>> Date: Sun, 16 Jul 2023 10:22:38 +0000
>> 
>> Stefan Monnier <monnier@HIDDEN> writes:
>> 
>> >>   . prevent_redisplay_optimizations_p flag of a buffer
>> >>   . must_be_updated_p flag of a window
>> >
>> > No idea what these mean.
>> > The name `must_be_updated_p` makes it sound to me like it's redundant
>> > with the `redisplay` flag above.
>> 
>> I agree about must_be_updated_p. I had exactly same though that it is
>> redundant with redisplay flag when reading the code.
>
> Actually, the must_be_updated_p flag is not for xdisp.c, i.e. not for
> redisplay_window and its subroutines.  It is for update_window, which
> is the last, 3rd, stage of a redisplay cycle, most of the code of
> which is in dispnew.c.  That's where the newly computed glyph matrix
> of a window is compared to its current matrix, and Emacs decides what,
> if anything, should be actually written to the glass.  What happens
> with this flag is that redisplay_window and friends _set_ this flag
> for windows that dispnew.c _must_ update.  The flag is tested in
> dispnew.c, see there for its use and comments.

I see.

I have to say that these flag names are very disorienting.
I have first seen this flag while reading xdisp.c, and it was not obvious
at all what it does.

The name must_be_updated has no link with glyph matrix terminology, and
it is only explained in the commentary in window.h. But then, at the
point of reading commentary I was not yet familiar with xdisp...

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Stefan Monnier <monnier@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Sun, 16 Jul 2023 22:21:02 +0000
Resent-Message-ID: <handler.64596.B64596.168954600725825 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168954600725825
          (code B ref 64596); Sun, 16 Jul 2023 22:21:02 +0000
Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 22:20:07 +0000
Received: from localhost ([127.0.0.1]:48714 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qLA63-0006iQ-3w
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 18:20:07 -0400
Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:48980)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <monnier@HIDDEN>) id 1qLA60-0006hn-QN
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 18:20:06 -0400
Received: from pmg1.iro.umontreal.ca (localhost.localdomain [127.0.0.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 86C981000C4;
 Sun, 16 Jul 2023 18:19:59 -0400 (EDT)
Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1])
 by pmg1.iro.umontreal.ca (Proxmox) with ESMTP id 96E09100097;
 Sun, 16 Jul 2023 18:19:58 -0400 (EDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca;
 s=mail; t=1689545998;
 bh=LfJ/rb0myeZg6oAhsDPyxICFqd79PENcJ9RuaI/V8Dc=;
 h=From:To:Cc:Subject:In-Reply-To:References:Date:From;
 b=GINk6S3Q5kuw598mudQo4pomFfqkuoP5nlifgXIdQynzfj9qioizXb4rO/KJkFelz
 5p+tuvhhBax3ig/h65JcwdC4xrGEJKbyHpH0oYxT/qdk00p7s8dxhr+Rs8l6vrQ4DQ
 3Cey54oFOXp2HE0cm+C1GtA+hOkIWqu1YmOTqS7V4FmWtQEOoCHqHzyGQrVUrmmjQ/
 0nbJnu/le4B7PWKbHZKlF/4jKD+vO93i9fHirZ3em9c+Fd8yIaAvoQY9SAbUxCWExs
 g/9HzOamrUlI7ct9IMWD8FPm0U2PWblyXuomaE234AQkKMmT0vuA0yFGWtJmB7GSPX
 +axCr9Ro/6rMQ==
Received: from pastel (unknown [108.175.226.218])
 by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 68A101202B9;
 Sun, 16 Jul 2023 18:19:58 -0400 (EDT)
From: Stefan Monnier <monnier@HIDDEN>
In-Reply-To: <83edl78yly.fsf@HIDDEN> (Eli Zaretskii's message of "Sun, 16 Jul
 2023 22:06:49 +0300")
Message-ID: <jwv8rbf8q4n.fsf-monnier+emacs@HIDDEN>
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
 <87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
 <83pm4r9apt.fsf@HIDDEN> <jwvsf9n969o.fsf-monnier+emacs@HIDDEN>
 <83mszv93yb.fsf@HIDDEN> <jwvfs5n8ztc.fsf-monnier+emacs@HIDDEN>
 <83edl78yly.fsf@HIDDEN>
Date: Sun, 16 Jul 2023 18:19:57 -0400
User-Agent: Gnus/5.13 (Gnus v5.13)
MIME-Version: 1.0
Content-Type: text/plain
X-SPAM-INFO: Spam detection results:  0
 ALL_TRUSTED                -1 Passed through trusted hosts only via SMTP
 AWL 0.182 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 DKIM_SIGNED               0.1 Message has a DKIM or DK signature,
 not necessarily valid
 DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature
 DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's
 domain
 DKIM_VALID_EF -0.1 Message has a valid DKIM or DK signature from envelope-from
 domain T_SCC_BODY_TEXT_LINE    -0.01 -
X-SPAM-LEVEL: 
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> That's not all of the uses of this flag.  Here's one example of other
> uses:
>
> 	  if (some_windows
> 	      && !f->redisplay
> 	      && !w->redisplay
> 	      && !XBUFFER (w->contents)->text->redisplay)
> 	    continue;
>
> (This avoids updating the tool bar and the tab bar of the frame, and
> there's a similar condition that avoids updating the frame's title.)

Right, but notice that what we're fundamentally checking is whether `w`
(which is the frame's selected window here) needs to be updated, because
that's the one currently "occupying" the tool-bar.

FWIW, I don't know why we don't also check
`XBUFFER(w->contents)->redisplay` here.

Also, I still don't see why that makes you think:

    frame's redisplay flag is what causes us to consider a frame in the
    first place.

Indeed, a frame's redisplay flag may be such a reason, but a window's
flag or its text buffer's may be the reason instead.  A frame's
`redisplay` flag does not need to be set for us to consider it.


        Stefan

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 17 Jul 2023 02:24:01 +0000
Resent-Message-ID: <handler.64596.B64596.168956061316580 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168956061316580
          (code B ref 64596); Mon, 17 Jul 2023 02:24:01 +0000
Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 02:23:33 +0000
Received: from localhost ([127.0.0.1]:48775 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qLDtc-0004JM-TV
	for submit <at> debbugs.gnu.org; Sun, 16 Jul 2023 22:23:33 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:60392)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qLDtX-0004J6-On
 for 64596 <at> debbugs.gnu.org; Sun, 16 Jul 2023 22:23:31 -0400
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 <eliz@HIDDEN>)
 id 1qLDtS-0000Xn-7b; Sun, 16 Jul 2023 22:23:22 -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=ZNpJd8yFIarfrv30WEjSX53CLHu/yzOB+DM9eyYdK4A=; b=n/UVdt5X2M2T
 IY2qQiPTEe/8lxmr71Arcf4heMGW3EPBrC2rjOKsK7fnPpYWRnfxiAPbGijAQKItq5InclHn1JzW5
 g48KtbhEIsgp9zLjGXH+KnfdYB83iah32uISLCdZCFX/JxVFuEaeaVN0Xi2V14f85X/Iy3WQR280E
 yvfqUi//MZ5054dcXNCIjIjGd/BjKfEbEP6hZDiJQvH0nG3vZxO3E88a2tm2AsvsQAcFBSUw803QI
 2pm5KGdQHPaF/QzvbmwXvHJyVKl7Y7xDMUSEnFJuAr8K97dKiJ+sNBUA9S/dlGeUYPSqGhS2nXyjw
 DR9pw4Y7pjimu6wru8gegA==;
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 <eliz@HIDDEN>)
 id 1qLDtR-0000xT-So; Sun, 16 Jul 2023 22:23:22 -0400
Date: Mon, 17 Jul 2023 05:23:46 +0300
Message-Id: <83a5vv8edp.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87jzuz1uq5.fsf@localhost> (message from Ihor Radchenko on Sun,
 16 Jul 2023 20:12:34 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost>
 <83bkgb8xo5.fsf@HIDDEN> <87jzuz1uq5.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 20:12:34 +0000
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> > Actually, the must_be_updated_p flag is not for xdisp.c, i.e. not for
> > redisplay_window and its subroutines.  It is for update_window, which
> > is the last, 3rd, stage of a redisplay cycle, most of the code of
> > which is in dispnew.c.  That's where the newly computed glyph matrix
> > of a window is compared to its current matrix, and Emacs decides what,
> > if anything, should be actually written to the glass.  What happens
> > with this flag is that redisplay_window and friends _set_ this flag
> > for windows that dispnew.c _must_ update.  The flag is tested in
> > dispnew.c, see there for its use and comments.
> 
> I see.
> 
> I have to say that these flag names are very disorienting.
> I have first seen this flag while reading xdisp.c, and it was not obvious
> at all what it does.

Well, update_frame and update_window are the relevant functions in
dispnew.c, so "must_be_updated_p" kind-of points to them.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: martin rudalics <rudalics@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 17 Jul 2023 08:31:01 +0000
Resent-Message-ID: <handler.64596.B64596.168958264031552 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: yantar92@HIDDEN, monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168958264031552
          (code B ref 64596); Mon, 17 Jul 2023 08:31:01 +0000
Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 08:30:40 +0000
Received: from localhost ([127.0.0.1]:49020 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qLJcu-0008BU-8X
	for submit <at> debbugs.gnu.org; Mon, 17 Jul 2023 04:30:40 -0400
Received: from mout.gmx.net ([212.227.17.22]:44757)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <rudalics@HIDDEN>) id 1qLJcq-0007mW-7o
 for 64596 <at> debbugs.gnu.org; Mon, 17 Jul 2023 04:30:38 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.at;
 s=s31663417; t=1689582625; x=1690187425; i=rudalics@HIDDEN;
 bh=RW3Dfxm+BcU5w8WgAuokLAKH42vd3tkBjuZ17YjU4AU=;
 h=X-UI-Sender-Class:Date:Subject:To:Cc:References:From:In-Reply-To;
 b=UrMVDPqqKGfDNbbKdsrTKBUMOGkHUJ5ePZPJPBdCHgfdO4mbYbXigK/XQ/qKXsDr6hhbdnf
 Lz+WLTiizldrv7GuPUELfiioLxG/2ZE9l8ck4TEQqdZsDvvPfcz5f/cu/t93026akW6ary67I
 FwO2LM1ihLQy/Zr6Ky/7279y+ccsA6Je76tImkqEqSccxrUgPaFADFd8GaFWupVZgFPTGU2MC
 3JzcraqKKiVYU28WvBYMe3dnqiT2Tpx2QsJWL9gZX0oZya42M3Hx34Yhaj/RUvMifq/LTbr+F
 oxkpHQvKLJQxVVkPXyQ6sMofVty6BLckWSTOi1Yn43VhCIzCqAaQ==
X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a
Received: from [192.168.1.100] ([46.125.249.31]) by mail.gmx.net (mrgmx105
 [212.227.17.168]) with ESMTPSA (Nemesis) id 1Mxm3K-1q0jXj1zjC-00zJMC; Mon, 17
 Jul 2023 10:30:25 +0200
Message-ID: <edfda92f-91c4-5c7b-ec32-5ca486a28eaa@HIDDEN>
Date: Mon, 17 Jul 2023 10:30:23 +0200
MIME-Version: 1.0
Content-Language: en-US
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <83r0p9b3om.fsf@HIDDEN>
 <jwvo7kdb2io.fsf-monnier+emacs@HIDDEN> <83jzv1b152.fsf@HIDDEN>
 <jwv7cr1aw2k.fsf-monnier+emacs@HIDDEN> <83a5vxas9k.fsf@HIDDEN>
 <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@HIDDEN>
 <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@HIDDEN> <83fs5o9r5l.fsf@HIDDEN>
From: martin rudalics <rudalics@HIDDEN>
In-Reply-To: <83fs5o9r5l.fsf@HIDDEN>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-Provags-ID: V03:K1:g/lqA41Wg46TV5QKcKk0ATukofKczgB1Xlx43QkB5nyIfXDdLGB
 G+Y1YqYEVypiimZbzKpLAHCKVwAlYInXlhb9GBRbR9RgzdULz4puAO0ZwI8PeFkHrDhIYpa
 6RmDD5m8cg0w2CcwY2CoQ9ys9XLF9TBbOdQvZJri/dLrH8UqA5QA5soQh7K64Z+9Xu63Ejw
 +4yFGS+HCCuXyWghi1epQ==
X-Spam-Flag: NO
UI-OutboundReport: notjunk:1;M01:P0:B0DGzwH/Mbc=;rWqhcpUfGU1VQxQQdNHGDOdsBJm
 5YniWqzIv9suwBXSOE7RTZ5dxkPhhJNw631irX/ONdcXXhsLwNfgeXyuGtAnDdhEls709ZmGG
 NOF+IrsLLVdr9Kdeik6B+zczNfeasl2+WMSuesSDgIm0MMl7J5URp18TFiiEt0OB/IorzpliJ
 yLhKn/nNqKYbH6WA81OWrZE44+b4Q5WtVyEeckeW8P1Velj1pLcIO0EvlrLUHqK2oUWAlNMGu
 +vBoqJJwdHqCG7LonjI8dA2aLmUapRSU+3DqlwGne5D/c3H04l3kiBffvrLl+3FyUch2Xbrw6
 nJXUsOkHM3oE9iHOpWWT9Pj6FllTJ5/bLHwBkKomX6nuzTaYZtuqFhLp9oNtjjIlXvZxO9kuZ
 Y5IEi9TvGnaKZ/ABtOtPF0LYiYvsD87o+IsqhVzUgyRHALEtNrjVArJZERzUf6k1vOMovE/yk
 d8TyDEBb4VAIpkyN+xlvX4r8fVz0LevrU+IFVgjtxnyLzzN9dXwFr/DlSF3l4TCQxDhxmT4WM
 ZRrie3KKC2Lq4nr/yeD+c6U8oQ4MOEcm/VvbnN4asYaeSc3T2YG30o8fYW4Qcjry6XhX3aB0S
 1xoOZbzSDBLseZdUekHaloRwL4YfknYXvIfO/yau6ysA+TbU2hFasTujP4EIWVryHRAceOhPU
 dGKZ/+00mdGIpC3NTtVtIqYyt3yv6yRHY1soiC2ogqZGQv6FRgbnDFbvSF9Bo4qiEYOWrq8HO
 j9UzCxBuUULmqssUSPQjRXN+6vz7UAjS6QarcAaLUun6o8BAwhsELbAxu5t8811WMzArRQoMG
 h8rig6+1M1PBB5hFKJdlIsk0x002rQvnODB2XtPi/pzTTlos8L++riVberAfHchWJs/MTMBVO
 eCuECIOFeIpMvtJB0bLVwHQURR7gXLlA9GY9hwT0NGApDbP9/52jZ+A6ZHGcngT49niPF61hN
 RJ/0RezGcDWiCHbR418bgjvaZIU=
X-Spam-Score: 2.8 (++)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 Content preview:  > The information flow is > unidirectional: the functions
 which change the windows should tell > what they changed, and redisplay will
 then decide what that requires. > For example, if some windows c [...] 
 Content analysis details:   (2.8 points, 10.0 required)
 pts rule name              description
 ---- ---------------------- --------------------------------------------------
 3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
 [46.125.249.31 listed in zen.spamhaus.org]
 -0.0 SPF_PASS               SPF: sender matches SPF record
 0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
 0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
 provider (rudalics[at]gmx.at)
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
 [212.227.17.22 listed in wl.mailspike.net]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
 low trust [212.227.17.22 listed in list.dnswl.org]
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: 1.8 (+)
X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org",
 has NOT identified this incoming email as spam.  The original
 message has been attached to this so you can view it or label
 similar future email.  If you have any questions, see
 the administrator of that system for details.
 
 Content preview:  > The information flow is > unidirectional: the functions
    which change the windows should tell > what they changed, and redisplay will
    then decide what that requires. > For example, if some windows c [...] 
 
 Content analysis details:   (1.8 points, 10.0 required)
 
  pts rule name              description
 ---- ---------------------- --------------------------------------------------
  3.6 RCVD_IN_SBL_CSS        RBL: Received via a relay in Spamhaus SBL-CSS
                             [46.125.249.31 listed in zen.spamhaus.org]
 -0.7 RCVD_IN_DNSWL_LOW      RBL: Sender listed at https://www.dnswl.org/,
                             low trust
                             [212.227.17.22 listed in list.dnswl.org]
 -0.0 RCVD_IN_MSPIKE_H2      RBL: Average reputation (+2)
                             [212.227.17.22 listed in wl.mailspike.net]
 -0.0 SPF_PASS               SPF: sender matches SPF record
  0.0 SPF_HELO_NONE          SPF: HELO does not publish an SPF Record
  0.0 FREEMAIL_FROM          Sender email is commonly abused enduser mail
                             provider (rudalics[at]gmx.at)
 -0.0 T_SCC_BODY_TEXT_LINE   No description available.
 -1.0 MAILING_LIST_MULTI     Multiple indicators imply a widely-seen list
                             manager

 > The information flow is
 > unidirectional: the functions which change the windows should tell
 > what they changed, and redisplay will then decide what that requires.
 > For example, if some windows changed their dimensions, redisplay would
 > need to know which dimension changed.

The window code should have all necessary information at hand (but for
the final height of the mode lines) when redisplay starts but would have
to know what redisplay wants it to tell.  It would be easy to reserve
one bit on each window to tell that its width, left scroll bar, left
margin, left fringe, body width, right fringe, right margin, right
scroll bar or the height, header, tab, mode line, body and scroll bar
height changed.  And one bit for each of font, line spacing, start and
point position and the scrolling statuses of the window.  Maybe also one
bit for the left and top edge within the frame and the left and top body
edge of the window.

Once it has been established what redisplay wants to know, it would be
easy to transfer practically all notifications currently performed by
frame.c to window.c.  That is, gui_set_left_fringe would no longer
SET_FRAME_GARBAGED because the window code would decide whether the
width of any left fringe of any window affected should really change and
set the left_fringe_width_changed, the body_width_changed and maybe also
the left_body_edge_changed bit accordingly.

In addition there would probably be one window_changed bit per window to
tell redisplay that one of the bits above changed and one frame_changed
bit to tell redisplay that at least one window has its window_changed
bit set.  Then we probably should try to remove any special treatment of
the selected window in this regard, since with all our excursions, code
can never tell anyway which window will be the selected one at the time
redisplay starts.

Finally, redisplay would have to merge in all buffer text and position
changes for each window showing that buffer mostly as it does now and
separately consider a few frame changes like visibility.

Information flow would still be bidirectional for the mode lines: As
soon as redisplay has calculated their respective heights and these
should change (a rare case), the window code would have to be informed
about that, store the new heights, adjust the body height, recalculate
scroll bar dimensions and leave it to redisplay to decide whether to
calculate mode line heights again to avoid infinite recursion.

martin

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 17 Jul 2023 09:23:02 +0000
Resent-Message-ID: <handler.64596.B64596.16895857246218 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16895857246218
          (code B ref 64596); Mon, 17 Jul 2023 09:23:02 +0000
Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 09:22:04 +0000
Received: from localhost ([127.0.0.1]:49078 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qLKQe-0001cC-86
	for submit <at> debbugs.gnu.org; Mon, 17 Jul 2023 05:22:04 -0400
Received: from mout01.posteo.de ([185.67.36.65]:60083)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qLKQb-0001bh-Un
 for 64596 <at> debbugs.gnu.org; Mon, 17 Jul 2023 05:22:03 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout01.posteo.de (Postfix) with ESMTPS id 0BA6124002B
 for <64596 <at> debbugs.gnu.org>; Mon, 17 Jul 2023 11:21:55 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689585716; bh=gb8iJYc6cj1lH247gUq33hrfvzYKt55dm+11CD7z0z8=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=mUKpgS5v203C4B/TfYYSQTsP/v1cDoA+SE/AutjGJkfsG8meGw/PcuHW985wmK1Gk
 Tz0aItHsMECYMjmv6XCPrABLlxzW/XE93nhukx3dNFUF6SjmCowFwTP/8wPGmyRJNU
 MjI0fjwQx1TCfo5c6lWJRE/yx6cF/Zf2o+/B3UPfmtkeUE/RI06m5FpKmq6F8Ntb5r
 WfeYet1ooe3BhXolIC/15xNRNyllm2URXFbCBG5/U1GTY+JorO4rrEgKgTzvtS7jXI
 lWs0M/gmuysHUsR0rMc12ZEQbz6vNrjteZiQBJDp8YK3HVzma+SF4L/KikQ4xM3LZo
 30cAgzdJH9vsA==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R4Gmy6l7dz6ty2;
 Mon, 17 Jul 2023 11:21:54 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <83a5vv8edp.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost>
 <83bkgb8xo5.fsf@HIDDEN> <87jzuz1uq5.fsf@localhost>
 <83a5vv8edp.fsf@HIDDEN>
Date: Mon, 17 Jul 2023 09:22:07 +0000
Message-ID: <87ttu2zydc.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

>> > Actually, the must_be_updated_p flag is not for xdisp.c, i.e. not for
>> > redisplay_window and its subroutines.  It is for update_window, which
>> > is the last, 3rd, stage of a redisplay cycle, most of the code of
>> > which is in dispnew.c...
>> 
>> I have to say that these flag names are very disorienting.
>> I have first seen this flag while reading xdisp.c, and it was not obvious
>> at all what it does.
>
> Well, update_frame and update_window are the relevant functions in
> dispnew.c, so "must_be_updated_p" kind-of points to them.

This does not help the confusion, unfortunately.
Or maybe the terms "redisplay" and "update" should be explained better
somewhere near the top of xdisp.c. They clearly have different meaning,
but not for untrained eye.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 17 Jul 2023 11:20:02 +0000
Resent-Message-ID: <handler.64596.B64596.168959278819617 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Stefan Monnier <monnier@HIDDEN>
Cc: yantar92@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.168959278819617
          (code B ref 64596); Mon, 17 Jul 2023 11:20:02 +0000
Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 11:19:48 +0000
Received: from localhost ([127.0.0.1]:49138 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qLMGZ-00056K-MX
	for submit <at> debbugs.gnu.org; Mon, 17 Jul 2023 07:19:48 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:33176)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qLMGX-000564-63
 for 64596 <at> debbugs.gnu.org; Mon, 17 Jul 2023 07:19:46 -0400
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 <eliz@HIDDEN>)
 id 1qLMGQ-0003OS-QO; Mon, 17 Jul 2023 07:19:38 -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=NCBsiLfVDzxZZsYm25kKVof6D4AUH33s4tgjBswGl4Q=; b=Zq0Q80HCbbjN
 uZNE5A6jTUTRiZTRd2muZ0KHDftMndTy9RxbOLH9OV/7NmqCJE7H08fmepe819UevRPhE1LqpX0Wh
 vVK3iyF29uUR5AzbrggKej3Jo6aftfjkiz2Tck88Y0JYPWPCJFjbWFoyrgYi8gqDOWhiEaNsQ72lc
 Vv9DsXC36A86QiS5NQaUK3XFyCimiAGydNztv61xKmJZ0BA7matwWzfnoltKMEJeQ+PD99JRfpaWo
 ImOPqwyWGIyjfdGXjBWISKY7EmlhsRGoSDf1Kk9x3pOCvWvfWOl7P5gyY0QTFoipNq5QIKEUUwBSK
 0MW3hyB+Oxr34yR5EPiGfQ==;
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 <eliz@HIDDEN>)
 id 1qLMGQ-00052q-AD; Mon, 17 Jul 2023 07:19:38 -0400
Date: Mon, 17 Jul 2023 14:20:04 +0300
Message-Id: <838rbe944b.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <jwv8rbf8q4n.fsf-monnier+emacs@HIDDEN> (message from Stefan
 Monnier on Sun, 16 Jul 2023 18:19:57 -0400)
References: <877cr4nez9.fsf@localhost> <jwvv8envj39.fsf-monnier+emacs@HIDDEN>
 <83lefj4okb.fsf@HIDDEN> <jwvfs5riihv.fsf-monnier+emacs@HIDDEN>
 <83fs5r3tqv.fsf@HIDDEN> <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN>
 <834jm6fppc.fsf@HIDDEN> <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN>
 <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@HIDDEN>
 <83a5vxejz6.fsf@HIDDEN> <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN>
 <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@HIDDEN>
 <87ilakgmjo.fsf@localhost> <jwv4jm49c1w.fsf-monnier+emacs@HIDDEN>
 <83pm4r9apt.fsf@HIDDEN> <jwvsf9n969o.fsf-monnier+emacs@HIDDEN>
 <83mszv93yb.fsf@HIDDEN> <jwvfs5n8ztc.fsf-monnier+emacs@HIDDEN>
 <83edl78yly.fsf@HIDDEN> <jwv8rbf8q4n.fsf-monnier+emacs@HIDDEN>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Stefan Monnier <monnier@HIDDEN>
> Cc: yantar92@HIDDEN,  64596 <at> debbugs.gnu.org
> Date: Sun, 16 Jul 2023 18:19:57 -0400
> 
> > That's not all of the uses of this flag.  Here's one example of other
> > uses:
> >
> > 	  if (some_windows
> > 	      && !f->redisplay
> > 	      && !w->redisplay
> > 	      && !XBUFFER (w->contents)->text->redisplay)
> > 	    continue;
> >
> > (This avoids updating the tool bar and the tab bar of the frame, and
> > there's a similar condition that avoids updating the frame's title.)
> 
> Right, but notice that what we're fundamentally checking is whether `w`
> (which is the frame's selected window here) needs to be updated, because
> that's the one currently "occupying" the tool-bar.

But testing the frame's redisplay flag will produce false positives,
because many changes that require to redraw the frame's windows don't
affect the tool bar or the frame's title.

> FWIW, I don't know why we don't also check
> `XBUFFER(w->contents)->redisplay` here.

We do:

 	  if (some_windows
 	      && !f->redisplay
 	      && !w->redisplay
 	      && !XBUFFER (w->contents)->text->redisplay)  <<<<<<<<<<<
 	    continue;

> Also, I still don't see why that makes you think:
> 
>     frame's redisplay flag is what causes us to consider a frame in the
>     first place.
> 
> Indeed, a frame's redisplay flag may be such a reason, but a window's
> flag or its text buffer's may be the reason instead.  A frame's
> `redisplay` flag does not need to be set for us to consider it.

No, my point is that fset_redisplay shouldn't set
windows_or_buffers_changed.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 17 Jul 2023 11:54:01 +0000
Resent-Message-ID: <handler.64596.B64596.1689594833400 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.1689594833400
          (code B ref 64596); Mon, 17 Jul 2023 11:54:01 +0000
Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 11:53:53 +0000
Received: from localhost ([127.0.0.1]:49222 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qLMnY-00006N-DJ
	for submit <at> debbugs.gnu.org; Mon, 17 Jul 2023 07:53:53 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:44820)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qLMnT-000067-Dh
 for 64596 <at> debbugs.gnu.org; Mon, 17 Jul 2023 07:53:51 -0400
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 <eliz@HIDDEN>)
 id 1qLMnN-0003rw-Rc; Mon, 17 Jul 2023 07:53:41 -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=+OBqOVDViVeEta57hFN8DMqOn52k76PwHUYCtuCD9nM=; b=Vcr1Ox+4baLP
 FsKSH1VH4sMuwjMSufqlpuNYZsBoRSqIyfRDUz2RWSdlZDOdVffbcVW8RJSx4WzhTzJMcB5lbt2LE
 h+tRX4m9/pf+m7uOwqMYRDSmJOwA+wXOunI75mb/BgTtuHRG+budwWVLqjx2E1+MIVcnaJxSfZhsr
 TPT6vjo8JYY5GwPNiCxlGqpXTtHJkVC7dzd76QbeH74xHcZM5zKtOPALH6TyGRuPmzS+qidiGWy2G
 KY/4qUdUVf8ezhlw66Ib+KwHg4R2w1K5HN3YuDq+r8pd+EFm9IX9wmaroAkT9RSvJ94Mk801sx91H
 9+EvmrXiV91+fgEuzUanaQ==;
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 <eliz@HIDDEN>)
 id 1qLMnM-00050D-Ut; Mon, 17 Jul 2023 07:53:41 -0400
Date: Mon, 17 Jul 2023 14:54:06 +0300
Message-Id: <83351m92jl.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87ttu2zydc.fsf@localhost> (message from Ihor Radchenko on Mon,
 17 Jul 2023 09:22:07 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost>
 <83bkgb8xo5.fsf@HIDDEN> <87jzuz1uq5.fsf@localhost>
 <83a5vv8edp.fsf@HIDDEN> <87ttu2zydc.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Mon, 17 Jul 2023 09:22:07 +0000
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> >> > Actually, the must_be_updated_p flag is not for xdisp.c, i.e. not for
> >> > redisplay_window and its subroutines.  It is for update_window, which
> >> > is the last, 3rd, stage of a redisplay cycle, most of the code of
> >> > which is in dispnew.c...
> >> 
> >> I have to say that these flag names are very disorienting.
> >> I have first seen this flag while reading xdisp.c, and it was not obvious
> >> at all what it does.
> >
> > Well, update_frame and update_window are the relevant functions in
> > dispnew.c, so "must_be_updated_p" kind-of points to them.
> 
> This does not help the confusion, unfortunately.
> Or maybe the terms "redisplay" and "update" should be explained better
> somewhere near the top of xdisp.c. They clearly have different meaning,
> but not for untrained eye.

"Update" is the general name of the 3rd step of "redisplay cycle".  It
takes its name from the function which enters this step: update_frame.

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Ihor Radchenko <yantar92@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 17 Jul 2023 12:01:02 +0000
Resent-Message-ID: <handler.64596.B64596.1689595204998 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Eli Zaretskii <eliz@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.1689595204998
          (code B ref 64596); Mon, 17 Jul 2023 12:01:02 +0000
Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 12:00:04 +0000
Received: from localhost ([127.0.0.1]:49229 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qLMtX-0000G2-WB
	for submit <at> debbugs.gnu.org; Mon, 17 Jul 2023 08:00:04 -0400
Received: from mout02.posteo.de ([185.67.36.66]:53371)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <yantar92@HIDDEN>) id 1qLMtR-0000Ev-RE
 for 64596 <at> debbugs.gnu.org; Mon, 17 Jul 2023 08:00:02 -0400
Received: from submission (posteo.de [185.67.36.169]) 
 by mout02.posteo.de (Postfix) with ESMTPS id E64A2240105
 for <64596 <at> debbugs.gnu.org>; Mon, 17 Jul 2023 13:59:51 +0200 (CEST)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017;
 t=1689595191; bh=Gt2/0dbjxYafnZodPgMxyAx8tSUafVMTs81ux+1Bxn0=;
 h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From;
 b=huwDZmeWcoiwP9bx6bABPKMDXPNwh85kr4X/9lviEEK+F08II+m11rst3sMT3p0sw
 YMVco+/w0VTpAutW1Vh81Lc+fVHnBOPxD3iuZXaqXb22NEhcrigclq+xfqxUumulvX
 TTVIY3lH4JsxTAwwpij6ni+Ix1kHM+2t6ZsnXa15sKnf2qs6c9DduSzukeyOqbrAbw
 5Rft8f/IsvDsDiyiE/I1/8VIafHD1vYRpUGYx4EzQ91UffFVAi10/ju3orh9qedxGl
 cIQiQn2rcJFwsoAk6Bbok+zZpk1Sqh7wkP+vSbA1Gu04A9GObPF4sAouFn0zTObovM
 UjsaDeG0qRzfw==
Received: from customer (localhost [127.0.0.1])
 by submission (posteo.de) with ESMTPSA id 4R4LHB45hMz6twS;
 Mon, 17 Jul 2023 13:59:50 +0200 (CEST)
From: Ihor Radchenko <yantar92@HIDDEN>
In-Reply-To: <83351m92jl.fsf@HIDDEN>
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost>
 <83bkgb8xo5.fsf@HIDDEN> <87jzuz1uq5.fsf@localhost>
 <83a5vv8edp.fsf@HIDDEN> <87ttu2zydc.fsf@localhost>
 <83351m92jl.fsf@HIDDEN>
Date: Mon, 17 Jul 2023 12:00:02 +0000
Message-ID: <87y1jeiw8t.fsf@localhost>
MIME-Version: 1.0
Content-Type: text/plain
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

Eli Zaretskii <eliz@HIDDEN> writes:

>> This does not help the confusion, unfortunately.
>> Or maybe the terms "redisplay" and "update" should be explained better
>> somewhere near the top of xdisp.c. They clearly have different meaning,
>> but not for untrained eye.
>
> "Update" is the general name of the 3rd step of "redisplay cycle".  It
> takes its name from the function which enters this step: update_frame.

May someone then detail these steps in the top commentary in xdisp.c +
highlight that redisplay term is generally used when deciding if we need
to update. And update is an actual process of putting desired matrix
onto the glass.

-- 
Ihor Radchenko // yantar92,
Org mode contributor,
Learn more about Org mode at <https://orgmode.org/>.
Support Org development at <https://liberapay.com/org-mode>,
or support my work at <https://liberapay.com/yantar92>

Message sent to bug-gnu-emacs@HIDDEN:

X-Loop: help-debbugs@HIDDEN
Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update)
Resent-From: Eli Zaretskii <eliz@HIDDEN>
Original-Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
Resent-CC: bug-gnu-emacs@HIDDEN
Resent-Date: Mon, 17 Jul 2023 12:23:01 +0000
Resent-Message-ID: <handler.64596.B64596.16895965584297 <at> debbugs.gnu.org>
Resent-Sender: help-debbugs@HIDDEN
X-GNU-PR-Message: followup 64596
X-GNU-PR-Package: emacs
X-GNU-PR-Keywords: 
To: Ihor Radchenko <yantar92@HIDDEN>
Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
Received: via spool by 64596-submit <at> debbugs.gnu.org id=B64596.16895965584297
          (code B ref 64596); Mon, 17 Jul 2023 12:23:01 +0000
Received: (at 64596) by debbugs.gnu.org; 17 Jul 2023 12:22:38 +0000
Received: from localhost ([127.0.0.1]:49298 helo=debbugs.gnu.org)
	by debbugs.gnu.org with esmtp (Exim 4.84_2)
	(envelope-from <debbugs-submit-bounces <at> debbugs.gnu.org>)
	id 1qLNFN-00017E-RE
	for submit <at> debbugs.gnu.org; Mon, 17 Jul 2023 08:22:38 -0400
Received: from eggs.gnu.org ([2001:470:142:3::10]:54722)
 by debbugs.gnu.org with esmtp (Exim 4.84_2)
 (envelope-from <eliz@HIDDEN>) id 1qLNFL-00016x-NU
 for 64596 <at> debbugs.gnu.org; Mon, 17 Jul 2023 08:22:36 -0400
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 <eliz@HIDDEN>)
 id 1qLNFG-0002hW-CL; Mon, 17 Jul 2023 08:22:30 -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=27XZxaEeKT/VQlfDEtvBCkf9U+BeN61niPqsT/2lrZo=; b=XUyYxoB2XiqN
 uwad02S6OBAhvKU2KZtE/pv88fcqJM42xMzZpitGz68X+DdRD0JNGHvBUy58KZ8sXeTEROl1/Gqmr
 sNB7F/XtwHhj8nPIhTL8CklOBP2esFn7Js0KE0zDS2eqCtOnDze92/MHqsBxH8/rhCjZ4EUy0mrQQ
 +tu7JmNHbXUEJkC+67DMgUPlUCBdUTdCNiEYso7W0mJyyCZwf8cHMTJ6McKgg29MgQfcnkuv/1i6j
 FEibKzVoV/q8dX6MbPAZ3/1WC8abGew+9HKb27KXywy/EEjkey28gk54xACckcF35iKzumjbbjToc
 jqEtsZxhIXVliHc5Mq+rgw==;
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 <eliz@HIDDEN>)
 id 1qLNFF-0004wm-S8; Mon, 17 Jul 2023 08:22:30 -0400
Date: Mon, 17 Jul 2023 15:22:55 +0300
Message-Id: <831qh6917k.fsf@HIDDEN>
From: Eli Zaretskii <eliz@HIDDEN>
In-Reply-To: <87y1jeiw8t.fsf@localhost> (message from Ihor Radchenko on Mon,
 17 Jul 2023 12:00:02 +0000)
References: <877cr4nez9.fsf@localhost>
 <jwvv8envj39.fsf-monnier+emacs@HIDDEN> <83lefj4okb.fsf@HIDDEN>
 <jwvfs5riihv.fsf-monnier+emacs@HIDDEN> <83fs5r3tqv.fsf@HIDDEN>
 <jwvpm4uefqv.fsf-monnier+emacs@HIDDEN> <834jm6fppc.fsf@HIDDEN>
 <jwvsf9qcs5p.fsf-monnier+emacs@HIDDEN> <87a5vyidy6.fsf@localhost>
 <83sf9qe2ip.fsf@HIDDEN> <83a5vxejz6.fsf@HIDDEN>
 <jwvbkgdcl4w.fsf-monnier+emacs@HIDDEN> <87ttu4gnpt.fsf@localhost>
 <83bkgb8xo5.fsf@HIDDEN> <87jzuz1uq5.fsf@localhost>
 <83a5vv8edp.fsf@HIDDEN> <87ttu2zydc.fsf@localhost>
 <83351m92jl.fsf@HIDDEN> <87y1jeiw8t.fsf@localhost>
X-Spam-Score: -2.3 (--)
X-BeenThere: debbugs-submit <at> debbugs.gnu.org
X-Mailman-Version: 2.1.18
Precedence: list
List-Id: <debbugs-submit.debbugs.gnu.org>
List-Unsubscribe: <https://debbugs.gnu.org/cgi-bin/mailman/options/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=unsubscribe>
List-Archive: <https://debbugs.gnu.org/cgi-bin/mailman/private/debbugs-submit/>
List-Post: <mailto:debbugs-submit <at> debbugs.gnu.org>
List-Help: <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=help>
List-Subscribe: <https://debbugs.gnu.org/cgi-bin/mailman/listinfo/debbugs-submit>, 
 <mailto:debbugs-submit-request <at> debbugs.gnu.org?subject=subscribe>
Errors-To: debbugs-submit-bounces <at> debbugs.gnu.org
Sender: "Debbugs-submit" <debbugs-submit-bounces <at> debbugs.gnu.org>
X-Spam-Score: -3.3 (---)

> From: Ihor Radchenko <yantar92@HIDDEN>
> Cc: monnier@HIDDEN, 64596 <at> debbugs.gnu.org
> Date: Mon, 17 Jul 2023 12:00:02 +0000
> 
> Eli Zaretskii <eliz@HIDDEN> writes:
> 
> >> This does not help the confusion, unfortunately.
> >> Or maybe the terms "redisplay" and "update" should be explained better
> >> somewhere near the top of xdisp.c. They clearly have different meaning,
> >> but not for untrained eye.
> >
> > "Update" is the general name of the 3rd step of "redisplay cycle".  It
> > takes its name from the function which enters this step: update_frame.
> 
> May someone then detail these steps in the top commentary in xdisp.c +
> highlight that redisplay term is generally used when deciding if we need
> to update.

It's already in the large commentary at the beginning of xdisp.c
(search for "update_window" to find the description of "update").  It
just "drowns" in the sea of the information there

> And update is an actual process of putting desired matrix onto the
> glass.

That's a very simplistic description of what "update" does.  Even the
comment in xdisp.c says more.

Last modified: Mon, 17 Jul 2023 12:30:01 UTC

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