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: Sun, 16 Jul 2023 11:50:14 +0300 Message-ID: <83fs5o9r5l.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> <83a5vxejz6.fsf@gnu.org> <83r0p9b3om.fsf@gnu.org> <83jzv1b152.fsf@gnu.org> <83a5vxas9k.fsf@gnu.org> <877cr1nep6.fsf@localhost> <835y6kbgik.fsf@gnu.org> <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@gmx.at> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="22560"; mail-complaints-to="usenet@ciao.gmane.io" Cc: yantar92@posteo.net, monnier@iro.umontreal.ca, 64596@debbugs.gnu.org To: martin rudalics Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sun Jul 16 10:51:32 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 1qKxTW-0005eh-Te for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Jul 2023 10:51:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qKxT6-0001rz-7y; Sun, 16 Jul 2023 04:51: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 1qKxT4-0001rX-CW for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 04:51: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 1qKxT4-0003Ql-4l for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 04:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qKxT3-0000uh-Uw for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 04:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Jul 2023 08:51:01 +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.16894974073439 (code B ref 64596); Sun, 16 Jul 2023 08:51:01 +0000 Original-Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 08:50:07 +0000 Original-Received: from localhost ([127.0.0.1]:46772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKxS7-0000tI-LN for submit@debbugs.gnu.org; Sun, 16 Jul 2023 04:50:06 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34774) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKxS3-0000se-3f for 64596@debbugs.gnu.org; Sun, 16 Jul 2023 04:50:02 -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 1qKxRw-00032Q-7E; Sun, 16 Jul 2023 04:49:52 -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=I56FnZqhEJ0mPPUaC9LV8IAZEAzEDya+cx+ofN+YIEY=; b=hufqSodAiKoK 5uqyJVvDXwmQEa67zhL1Iesy2T8XgsXzfVGR8wc+1sYnGBKBPKgp7ozTVe2PM1t0EJxBTaD8GKnzC 58lZEfRXtgufSTWFOYEM1jGy7BtjI1PnNZDJuGzqFITHWuIqj4Ht70ZLh0k/BQmE3C4BGJrXjR8/R dfjDhE590XT/9tUBZSJ1u6xMaqv0VjxNO882VSA1eFUhx4rpw42bqKoYJ678hHWb8cvDtvxnzdoN7 Q+7ZsI1EldbOR3fQGYlNhsYt2/1dAZvCKqU2IWmUofU/4kMofoRhxhmARtxgK1j+SoD2y5apfHv+f 6VTJhBOivK3tH5WYSI8TCw==; 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 1qKxRv-0002Ua-Nm; Sun, 16 Jul 2023 04:49:52 -0400 In-Reply-To: <682666d3-51f3-9097-1eff-c2c6c6bc5ac4@gmx.at> (message from martin rudalics on Sun, 16 Jul 2023 10:26:04 +0200) 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:265297 Archived-At: > Date: Sun, 16 Jul 2023 10:26:04 +0200 > Cc: monnier@iro.umontreal.ca, 64596@debbugs.gnu.org > From: martin rudalics > > From the POV of window management the situation is simple: When the size > of a window or a decoration changes, it would like to tell redisplay > about it. But redisplay would have to tell it first which kind of > changes it's able to accept. I don't think this is required. The information flow is unidirectional: the functions which change the windows should tell what they changed, and redisplay will then decide what that requires. For example, if some windows changed their dimensions, redisplay would need to know which dimension changed. > For example, I don't even know whether, when running without window > matrices, redisplay is capable of doing something reasonable with > the fact that the border between two adjacent windows shifted and a > third window not affected by that shift can be spared by redisplay. If the third window displays a buffer that didn't change in any way, then yes, the display engine should be capable of doing the above. On TTY frames, the display engine considers the entire frame, so it should see that the portion corresponding to that third window didn't change, and refrain from redrawing it. > As an example: one of the worst things the window code does is saving a > window configuration, reading something from the minibuffer and > restoring the window configuration when done. In nine out of ten cases > the restored configuration will not have changed and redisplay wouldn't > have to do anything. Now Fset_window_configuration is awful in the > regard that it deletes all windows on the frame regardless of whether > the configuration changed only to "restore" them later (including that > n_leaf_windows allocation hack to find out which glyph matrices can be > safely freed). While it is fairly easy to fix that, it's by no means > clear what and how to tell redisplay that some window did change in one > of those rare cases where it did. We need to add flags that convey the information about which windows changed what dimensions. > (let (config) > (set-frame-parameter nil 'left-fringe 50) > (y-or-n-p "?") > (setq config (current-window-configuration)) > (setq left-fringe-width 0) > (set-window-buffer nil (window-buffer)) > (y-or-n-p "?") > (set-window-configuration config)) > > Here 'set-window-configuration' should be able to tell redisplay that it > should redisplay the window but it should be able to tell that iff the > fringe really changed which is fairly easy to find out. Once it found > out, which kind of flag would it set? I'm not even sure it must find that out. It could simply tell redisplay that the fringe really changed. The rest is up to the display engine to decide.