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: Sat, 15 Jul 2023 10:49:37 -0400 Message-ID: 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> 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="26211"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: yantar92@posteo.net, 64596@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 15 16:50:26 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 1qKgbJ-0006fV-Ef for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 Jul 2023 16:50:25 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKgaz-0000Fr-29; Sat, 15 Jul 2023 10:50:05 -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 1qKgaw-0000Fc-RF for bug-gnu-emacs@gnu.org; Sat, 15 Jul 2023 10:50: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 1qKgaw-0000yn-In for bug-gnu-emacs@gnu.org; Sat, 15 Jul 2023 10:50:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qKgaw-00088c-Ej for bug-gnu-emacs@gnu.org; Sat, 15 Jul 2023 10:50:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 15 Jul 2023 14:50: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.168943258731254 (code B ref 64596); Sat, 15 Jul 2023 14:50:02 +0000 Original-Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 14:49:47 +0000 Original-Received: from localhost ([127.0.0.1]:45744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKgag-000882-Vu for submit@debbugs.gnu.org; Sat, 15 Jul 2023 10:49:47 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21472) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKgae-00087p-Kn for 64596@debbugs.gnu.org; Sat, 15 Jul 2023 10:49:46 -0400 Original-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) Original-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== Original-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) In-Reply-To: <83a5vxejz6.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 15 Jul 2023 10:01:49 +0300") 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:265212 Archived-At: > 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