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: Sat, 15 Jul 2023 10:01:49 +0300 Message-ID: <83a5vxejz6.fsf@gnu.org> References: <877cr4nez9.fsf@localhost> <83lefj4okb.fsf@gnu.org> <83fs5r3tqv.fsf@gnu.org> <834jm6fppc.fsf@gnu.org> <87a5vyidy6.fsf@localhost> <83sf9qe2ip.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33295"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 64596@debbugs.gnu.org To: yantar92@posteo.net, monnier@iro.umontreal.ca Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jul 15 09:02:43 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 1qKZIh-0008ST-BZ for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 15 Jul 2023 09:02:43 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKZIB-0008Sx-EG; Sat, 15 Jul 2023 03:02:11 -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 1qKZI3-0008S5-Jy for bug-gnu-emacs@gnu.org; Sat, 15 Jul 2023 03:02: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 1qKZI3-0005j7-6e for bug-gnu-emacs@gnu.org; Sat, 15 Jul 2023 03:02:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qKZI2-00008F-UD for bug-gnu-emacs@gnu.org; Sat, 15 Jul 2023 03:02: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: Sat, 15 Jul 2023 07:02: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.1689404500457 (code B ref 64596); Sat, 15 Jul 2023 07:02:02 +0000 Original-Received: (at 64596) by debbugs.gnu.org; 15 Jul 2023 07:01:40 +0000 Original-Received: from localhost ([127.0.0.1]:43902 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKZHf-00007H-KU for submit@debbugs.gnu.org; Sat, 15 Jul 2023 03:01:40 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKZHd-000070-T8 for 64596@debbugs.gnu.org; Sat, 15 Jul 2023 03:01:39 -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 1qKZHY-0005Ma-2r; Sat, 15 Jul 2023 03:01:32 -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=kdqPjZ+1/DZZZkkuLkaNGu1HrKfHWEc5DdRL2kAIxKU=; b=MaoifD/BJrA1 OnKkzt3wo8/Skrwd2fogZOVyeHVmtnlGRBJv2wD5PAtHdeR2RPHkn5GRFecANdDf9OaNTAK/c2BTR n1Opj09ftvab95vk/qX51eYJAxfnjTbk/LHxxsPRxRTbgseQbr14kyuDtQ4kRQqrKoF9XzwQoC/Yo Q6QSXURHvEyjpTx3lw6fxMvN5UiJy/8jBIvDvKBr47Hc9c5vVFbSfjSkas9mM8Gc/nBFCp7wU7yoS DxkYokmauUn2TWSL1Zbm6JPZUbFpgcXHHy7kgvqKlB5wt8AOWldv2OKn70MefE5I8RJUJlHK2yt1g 1UaajZDdcLWeMUo+rjqTEQ==; 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 1qKZHV-00031E-3q; Sat, 15 Jul 2023 03:01:31 -0400 In-Reply-To: <83sf9qe2ip.fsf@gnu.org> (message from Eli Zaretskii on Fri, 14 Jul 2023 22:06:38 +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:265150 Archived-At: > Cc: monnier@iro.umontreal.ca, 64596@debbugs.gnu.org > Date: Fri, 14 Jul 2023 22:06:38 +0300 > From: Eli Zaretskii > > > From: Ihor Radchenko > > Cc: Eli Zaretskii , 64596@debbugs.gnu.org > > Date: Fri, 14 Jul 2023 17:46:09 +0000 > > > > Stefan Monnier writes: > > > > > What we need in order to investigate is a somewhat reproducible test > > > case and for that we need the bug to be exposed to as many users as > > > possible to increase the chance that one of them bumps into > > > a good recipe. > > > > > > The variable is not used to investigate, but to make it ethical to > > > expose users to those potential bugs because they can set the var to > > > recover the old behavior as soon as they're tired of playing the > > > guinea pig. > > > > +1. > > -1000 Let me explain once again my position on this. 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 . prevent_redisplay_optimizations_p flag of a buffer . clip_changed flag of a buffer . update_mode_line flag of a window . must_be_updated_p flag of a window . cursor_type_changed flag of a frame . face_change flag of a frame . update_mode_lines variable . windows_or_buffers_changed variable (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. But just knowing, for example, that a buffer's text was changed says almost nothing about which optimizations can and cannot be used, whether or not the mode line needs to be updated, nor even if the window(s) showing the buffer need to be redrawn (since the change could be in a portion of the buffer that is not visible in any of the windows). Anyway, we now have this dozen of flags and variables, and one of them is prevent_redisplay_optimizations_p. It makes absolutely no sense to me to try to "solve" the "problem" of this single flag in the single case that started this thread. Even if this flag should not be set in the particular place with a FIXME -- which was not convincingly demonstrated here -- so what? what harm can that possibly make in this specific case? None. What we have now might look untidy at best, but it does work, and works well. It took an effort to get here, but the current situation has been stable for several years: I don't remember any significant redisplay problems reported for the last several years. What we do need is to make some better order out of these flags, understand better what does each one of them tell the display engine, and perhaps make some of them more selective. And we need to document these understandings. So this is the deal: if someone wants to try to do this job, or even some part of it, you will have my full support, my attention, and any form of help I can practically provide. But I will not agree to random poking at this or that particular flag, unless there's convincing evidence that it causes a display bug or a significant performance problem. Because otherwise making changes in code that we don't sufficiently understand can only cause bugs, and guess who gets to work on fixing them.