From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" 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 10:20:32 -0400 Message-ID: References: <877cr4nez9.fsf@localhost> <83v8eo3pfv.fsf@gnu.org> <87bkgeiuap.fsf@localhost> Reply-To: Stefan Monnier Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="30316"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , 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 16:21:34 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 1qKJfp-0007ga-Q2 for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jul 2023 16:21:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKJfO-0003hX-5l; Fri, 14 Jul 2023 10:21:06 -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 1qKJfM-0003ge-Dn for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 10:21:04 -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 1qKJfL-00040W-Pf for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 10:21:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qKJfL-0002yj-KE for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 10:21:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 14 Jul 2023 14:21:03 +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.168934444211371 (code B ref 64596); Fri, 14 Jul 2023 14:21:03 +0000 Original-Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 14:20:42 +0000 Original-Received: from localhost ([127.0.0.1]:43140 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKJez-0002xJ-Ui for submit@debbugs.gnu.org; Fri, 14 Jul 2023 10:20:42 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:53340) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKJey-0002x3-BY for 64596@debbugs.gnu.org; Fri, 14 Jul 2023 10:20:40 -0400 Original-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) Original-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== Original-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) In-Reply-To: <87bkgeiuap.fsf@localhost> (Ihor Radchenko's message of "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:265097 Archived-At: > 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