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: Thu, 13 Jul 2023 16:34:44 +0300 Message-ID: <83v8eo3pfv.fsf@gnu.org> References: <877cr4nez9.fsf@localhost> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="19562"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 64596@debbugs.gnu.org To: Ihor Radchenko , Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jul 13 15:35:36 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 1qJwTn-0004pN-D1 for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 13 Jul 2023 15:35:35 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qJwTI-0007l8-J0; Thu, 13 Jul 2023 09:35:04 -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 1qJwTG-0007kr-ND for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2023 09:35:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qJwTG-0003aN-FK for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2023 09:35:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qJwTG-0000jg-2J for bug-gnu-emacs@gnu.org; Thu, 13 Jul 2023 09:35: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: Thu, 13 Jul 2023 13:35: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.16892552832786 (code B ref 64596); Thu, 13 Jul 2023 13:35:02 +0000 Original-Received: (at 64596) by debbugs.gnu.org; 13 Jul 2023 13:34:43 +0000 Original-Received: from localhost ([127.0.0.1]:53601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJwSx-0000is-2N for submit@debbugs.gnu.org; Thu, 13 Jul 2023 09:34:43 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:38280) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qJwSq-0000iR-Iz for 64596@debbugs.gnu.org; Thu, 13 Jul 2023 09:34:41 -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 1qJwSj-0003VK-3X; Thu, 13 Jul 2023 09:34:29 -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=slNUoZSrLoTqKKIauZV3ZgI+0c/6KxtoYYXwZq5n5G8=; b=dwafNwPRRFnO sXN92kxMGXtrIFbKWDTmGFnh30EF18lE6aA+Tg1j4nKrLie7ScijMt56PApdGtQUiUy1jZlB6OWqj eITiOohaeYUKrTxVmjhoo7kIkT1h8gOeBNoRO9X3HenNBTYlEcBKpdQAg8RJuz3SOIBOmKMQgjMS4 8QelzsnzF1okcZ368mw3rBxMduB1hN0gox87UJqMfyJ0gV1TGMb4RO8Mh6otz0QMoH0CM+VvDEqqz f7xNcx54PGwitnZqhrkFn3yxqaSBxTVhsx0VuGbRfheSdQFGa8UAgh3bHHK562P/lXBh8+cH2ycBJ GHEVCfo/kSyusSFBAhT3Uw==; 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 1qJwSh-0008K7-Bw; Thu, 13 Jul 2023 09:34:28 -0400 In-Reply-To: <877cr4nez9.fsf@localhost> (message from Ihor Radchenko on Thu, 13 Jul 2023 13:00:26 +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:265021 Archived-At: > From: Ihor Radchenko > 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.