From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#64596: 30.0.50; On FIXME: in src/buffer.c:1481 (force-mode-line-update) Date: Tue, 18 Jul 2023 14:51:08 +0300 Message-ID: <83cz0p780j.fsf@gnu.org> References: <877cr4nez9.fsf@localhost> <83lefj4okb.fsf@gnu.org> <83fs5r3tqv.fsf@gnu.org> <834jm6fppc.fsf@gnu.org> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@gnu.org> <83a5vxejz6.fsf@gnu.org> <87ttu4gnpt.fsf@localhost> <83bkgb8xo5.fsf@gnu.org> <87jzuz1uq5.fsf@localhost> <83a5vv8edp.fsf@gnu.org> <87ttu2zydc.fsf@localhost> <83351m92jl.fsf@gnu.org> <87y1jeiw8t.fsf@localhost> <831qh6917k.fsf@gnu.org> <87msztv95v.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7352"; mail-complaints-to="usenet@ciao.gmane.io" Cc: monnier@iro.umontreal.ca, 64596@debbugs.gnu.org To: Ihor Radchenko Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Jul 18 13:51:38 2023 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qLjEw-0001jq-II for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 18 Jul 2023 13:51:38 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qLjEd-0002B3-Lf; Tue, 18 Jul 2023 07:51:19 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qLjEN-00029Z-0u for bug-gnu-emacs@gnu.org; Tue, 18 Jul 2023 07:51:11 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qLjEM-0006iQ-66 for bug-gnu-emacs@gnu.org; Tue, 18 Jul 2023 07:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qLjEM-0001Ph-1c for bug-gnu-emacs@gnu.org; Tue, 18 Jul 2023 07:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 18 Jul 2023 11:51:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64596 X-GNU-PR-Package: emacs Original-Received: via spool by 64596-submit@debbugs.gnu.org id=B64596.16896810515412 (code B ref 64596); Tue, 18 Jul 2023 11:51:02 +0000 Original-Received: (at 64596) by debbugs.gnu.org; 18 Jul 2023 11:50:51 +0000 Original-Received: from localhost ([127.0.0.1]:51814 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLjEA-0001PD-Jj for submit@debbugs.gnu.org; Tue, 18 Jul 2023 07:50:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49194) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLjE6-0001Oz-Pb for 64596@debbugs.gnu.org; Tue, 18 Jul 2023 07:50:48 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qLjE0-0006e1-MN; Tue, 18 Jul 2023 07:50: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=bQspCJ8yHEzAF+RL3fFCkM2ytYH1v2IVKc7m5cJ5zVM=; b=GWn7+eMzH6O8 Vh10eFAYT77SQtQj4VuXqAiiBud2tMoiJLfnYNtNqHsM43jfUTVmwjYuLons91XXt4cIScogcQOn5 M7ctmGx78PPfA8hqZklStSlxb868UaYJvYwFRmQtfN40vXabkLmb1i/IiR56Yegmg9tYIJEexiQ5W x3dYU7nEW5WWaQmZCIrJI89BBhK3MPBNMW8Sl2sd8hSHAIM3P6uNDm6qn7ZJm4077coZWpvJo9CW7 Mibc/WJCDYWB1Xq2jQ8p0M6mtxeoPa262v8pH1Gqz+BJfRbzngG7b5mX/+65SYnfNPz/QAoTvhp6L nw8HvbqtRGg3r9PCtiSN3A==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qLjE0-0006rl-6G; Tue, 18 Jul 2023 07:50:40 -0400 In-Reply-To: <87msztv95v.fsf@localhost> (message from Ihor Radchenko on Tue, 18 Jul 2023 09:52:28 +0000) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:265447 Archived-At: > From: Ihor Radchenko > Cc: monnier@iro.umontreal.ca, 64596@debbugs.gnu.org > Date: Tue, 18 Jul 2023 09:52:28 +0000 > > Eli Zaretskii writes: > > >> 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 > > I saw this. But "update" is not used consistently across that > commentary. Tough. "Update" is too general a word to limit is use. Sorry. > If we read at the very beginning: > > /* New redisplay written by Gerd Moellmann . > > Redisplay. > > Emacs separates the task of updating the display from code > modifying global state, e.g. buffer text. ... > > Updating the display is triggered by the Lisp interpreter when it > decides it's time to do it.... > > Which immediately creates an impression that "redisplay" and "update" > are referring to the same thing. There's no practical way to avoid all the possible misinterpretations of this large and complex text, especially when it is read for the first time. > It would be nice the highlight the distinction rightaway there. If someone wants to work on making this commentary more clear, please do. But in general, I think we are splitting hair here. This commentary is intended as an introduction to reading the code and some kind of general guidelines. It doesn't pretend to be a detailed and comprehensive documentation of everything that happens in the display engine. Rest assured that there are important aspects and algorithms of the display engine that are completely absent from this commentary. > You will find a lot of redisplay optimizations when you start > looking at the innards of redisplay. The overall goal of all these > optimizations is to make redisplay fast because it is done > frequently. Some of these optimizations are implemented by the > following functions: > > focuses on optimizations related to window, but says nothing about > checking frames. Because nothing interesting happens on frames that can be described as "redisplay optimizations". The only situation where some important optimizations do happen there is on TTY frames, and that _is_ covered: see the section headed "Frame matrices". > It talks not about buffers displayed in multiple > windows either. Again, no redisplay optimizations consider multiple windows; they all work on a single window. And the text doesn't describe many more other things. Like I said: this is intended to be an introduction and a "guide for the perplexed", not a full and detailed documentation -- that would be a much larger job and a much longer text. Informative additions to this commentary are welcome, of course. > The rest of the commentary is diving deep into the "update" part. > Redisplay and its optimizations are not described in sufficient detail. This is a misunderstanding: where that part talks about "updating the display", it actually means updating the window's glyph matrix. The only "optimization" in the "update" part is that we write to the glass only the portions where the current and the desired glyph matrices differ, and cannot be made identical by moving pixels on the screen (as opposed to actually displaying new pixels).