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 09:14:00 +0300 Message-ID: <83fs5r3tqv.fsf@gnu.org> References: <877cr4nez9.fsf@localhost> <83lefj4okb.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18451"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, 64596@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jul 14 08:14:18 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 1qKC4I-0004aB-6G for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 14 Jul 2023 08:14:18 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKC44-0002M7-UV; Fri, 14 Jul 2023 02:14: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 1qKC42-0002JW-Pc for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 02:14: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 1qKC42-0006kF-Dr for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 02:14:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qKC42-0001yJ-9r for bug-gnu-emacs@gnu.org; Fri, 14 Jul 2023 02:14: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: Fri, 14 Jul 2023 06:14: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.16893152357558 (code B ref 64596); Fri, 14 Jul 2023 06:14:02 +0000 Original-Received: (at 64596) by debbugs.gnu.org; 14 Jul 2023 06:13:55 +0000 Original-Received: from localhost ([127.0.0.1]:41363 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKC3v-0001xq-Ag for submit@debbugs.gnu.org; Fri, 14 Jul 2023 02:13:55 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57142) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKC3r-0001xZ-8w for 64596@debbugs.gnu.org; Fri, 14 Jul 2023 02:13:53 -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 1qKC3j-0006WN-Vq; Fri, 14 Jul 2023 02:13:44 -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=c+oMUdm9A91ExEbeDMpOD4WKOzDUDbS/sK/EhsuQYy8=; b=OcJ9Qp8uW1TJ xFv7CQpaIXl6C5CjiJ/3rYov+a+yvL8xZbhlUxsaOZDth+SKEhF12VINUy0vbuZP4oNzRmcVtQeP+ WVEg/TiC/sDpkv/WQTCd5dfsJWdAk0AcElEmN0JvGODqc00alBMSbw4QpwiQzXdHNl5liTaLx4dH7 c4L5llmO0g7bC8jzAPZW9gwJxufXM+qI19kSv2pAf/ZEeSuoBQ6CkF5xgYwraf3PQOxZ5dQTsjWR5 nvdXghLOkGu58Py9pjIoAV6QXDs4GoOEBVb/w8FZn9CRJz814mjiTZzFU3gUelaPK1ZA986BdEyOo VsqbHWvkZ0f7z4CBAp5N7w==; 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 1qKC3h-00071A-Ff; Fri, 14 Jul 2023 02:13:41 -0400 In-Reply-To: (message from Stefan Monnier on Thu, 13 Jul 2023 18:02:26 -0400) 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:265070 Archived-At: > From: Stefan Monnier > Cc: yantar92@posteo.net, 64596@debbugs.gnu.org > Date: Thu, 13 Jul 2023 18:02:26 -0400 > > > Then I guess you or Ihor (or both) should try removing that line and > > run with that for a while. > > FWIW, I've been running without those two lines ever since I put this FIXME. I'd be happier with the alternative I proposed, which you cite below. Because bitter experience taught me that your, Stefan, usage patterns evidently exclude some use cases, because bug reports pop up after your similar changes where the display is not updated in some cases. I'm sure the same is true for the usage patterns of anyone of us, so doing this on a small number of systems is not enough. > > Alternatively, maybe in the case of ALL non-nil the code should set > > the prevent_redisplay_optimizations_p flag of all the buffers that are > > displayed in some window, since some redisplay optimizations are not > > eligible when the mode-line is about to be updated. > > Any reason why the corresponding optimizations don't consult the > `update_mode_lines` var (or the `update_mode_line` buffer flag), or > maybe have redisplay start by propagating the `update_mode_line` buffer > flag to `prevent_redisplay_optimizations_p`? Once again, prevent_redisplay_optimizations_p is NOT (just) about updating mode lines, it affects more optimizations. There's also windows_or_buffers_changed, which is even "stronger". For example, try_window_id checks the prevent_redisplay_optimizations_p flag and punts if it is set, although that optimization method AFAIK has nothing to do with redisplaying mode lines, it is only about updating the text area. It would be nice to analyze all those flags, make them more selective, and understand/document better what optimizations and optional processing are affected by each one of them. It is a large and somewhat ungrateful job, so if someone wants to do it by systematically examining the situations where we set each one of those flags and their effects on redisplay, I can offer my best help (though I cannot afford doing this job myself). Failing that, we could try disabling some portions of the code. This is not the best method of collecting such systematic information, IME, certainly not if just a couple of people do that, because experience teaches us that usage patterns differ wildly, and different window-systems and different window managers sometimes have significant effect on this stuff. So if we want to use this "phenomenological" approach, my suggestion is to allow disabling the relevant parts of the display-related code at run time, controlled by variables exposed to Lisp. We already have a bunch of inhibit-* variables that inhibit specific optimizations in xdisp.c; we could add more. Then we could set the defaults of these variables according to our best understanding, and if and when redisplay problems are reported, ask people to flip one or more of these inhibit-* variables and see if the problems go away. Again, this is not the best way, so if someone here is willing to do a thorough job regarding this, I encourage him or her to take the first way, although it is harder. The advantage is that we will have a much better understanding and documentation of these flags, and will probably be able to improve the ad-hoc set of flags we have today and make it easier to use and maintain. (Ideally, these flags should be a single bitmap with individual reasons representing the causes for disabling optimizations, and each optimization should examine the bits it cares about.)