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: Fri, 14 Jul 2023 15:25:24 +0300 Message-ID: <83fs5qfznv.fsf@gnu.org> References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@gnu.org> <87bkgeiuap.fsf@localhost> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21505"; 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 Fri Jul 14 14:26:11 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 1qKHsA-0005K1-O9 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jul 2023 14:26:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKHs3-0005wt-4h; Fri, 14 Jul 2023 08:26:03 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKHs2-0005wX-4M for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 08:26:02 -0400 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qKHs1-0005vX-SE for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 08:26:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qKHs1-0006ht-NG for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 08:26:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jul 2023 12:26:01 +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.168933752825701 (code B ref 64596); Fri, 14 Jul 2023 12:26:01 +0000 Original-Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 12:25:28 +0000 Original-Received: from localhost ([127.0.0.1]:41623 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKHrT-0006gT-FR for submit@debbugs.gnu.org; Fri, 14 Jul 2023 08:25:28 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36854) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKHrQ-0006g4-Uz for 64596@debbugs.gnu.org; Fri, 14 Jul 2023 08:25:26 -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 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==; 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 1qKHr7-0002d8-RY; Fri, 14 Jul 2023 08:25:13 -0400 In-Reply-To: <87bkgeiuap.fsf@localhost> (message from Ihor Radchenko on Fri, 14 Jul 2023 11:53:02 +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:265087 Archived-At: > From: Ihor Radchenko > Cc: Stefan Monnier , 64596@debbugs.gnu.org > Date: Fri, 14 Jul 2023 11:53:02 +0000 > > Eli Zaretskii 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?