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: Sun, 16 Jul 2023 12:44:08 -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> <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@gnu.org> <87ilakgmjo.fsf@localhost> <83pm4r9apt.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="2856"; 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 Sun Jul 16 18:45:27 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 1qL4sA-0000W8-G6 for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Jul 2023 18:45:26 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qL4ro-0004fx-V0; Sun, 16 Jul 2023 12:45: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 1qL4rm-0004fX-Mw for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 12:45: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 1qL4rm-000491-Dq for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 12:45:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qL4rl-00011r-Ve for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 12:45:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 16 Jul 2023 16:45: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.16895258583880 (code B ref 64596); Sun, 16 Jul 2023 16:45:01 +0000 Original-Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 16:44:18 +0000 Original-Received: from localhost ([127.0.0.1]:48445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qL4r4-00010W-2X for submit@debbugs.gnu.org; Sun, 16 Jul 2023 12:44:18 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:63451) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qL4r2-00010G-03 for 64596@debbugs.gnu.org; Sun, 16 Jul 2023 12:44:16 -0400 Original-Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id ADC54805BA; Sun, 16 Jul 2023 12:44:10 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 61EFC8044C; Sun, 16 Jul 2023 12:44:09 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1689525849; bh=PyVCZqLJQk5HeInVemtP2RyftT+JSA1sBmBQ2a1Rz8M=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=NdDqaZWctgu3w6R5RjtunIGfT65LLDhN8lPJfZToA9gXaweOSfQnCwdX+koVgl7N7 T/u0ZGdkGgAJjgXhUk2X4MtTGvnkEBMlnupv1et30YwJDmGPpFnDF05GtP/1W3JHxE RYgtI2I9SLI9DJLnXOwZkfuEDAzYNVlm7snz1/dKQCMAyzphgZ9p9ivAAQ1JmlcS7Q On0UEYj/X9tsuEdIhgeLGgCeJIZMfx6yrIOi37dtaDSEZ/gCx8JooKl5o6GzGw8/jx Jh8DwdPwQ+Xd1otReW7CLDmP6QSgAUJq2l+I97LsMxQikT4eIH4yfAKpr1cxAGF6kh ow6oeE4T5Wdeg== Original-Received: from pastel (unknown [108.175.226.218]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 3B21C1202B9; Sun, 16 Jul 2023 12:44:09 -0400 (EDT) In-Reply-To: <83pm4r9apt.fsf@gnu.org> (Eli Zaretskii's message of "Sun, 16 Jul 2023 17:45:18 +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:265350 Archived-At: >> 1- decide which windows may need to be updated. > > More accurately: > > 1a - decide whether all the windows need to be considered, or just > the selected window > 1b - if all the windows need to be considered, decide for each frame > whether it needs to be considered, and if so, consider all of > that frame's windows > > Considering a window can sometimes decide very quickly that the window > doesn't need to be redisplayed, but, as I mentioned elsewhere, when > its frame's redisplay flag is set, we never decide that, and the > frame's redisplay flag is what causes us to consider a frame in the > first place. Hmm... I'm not sure why you're saying frame's redisplay flag is what causes us to consider a frame in the first place. AFAICT the main place where we check a frame's `redisplay` bit is in `needs_no_redisplay` which operates on a window. In most cases a frame's `redisplay` bit should not be set, tho some of its windows' `redisplay` bits may be set, and we will consider this frame and all its windows (to find those that need to be updated). >> BTW, I wish those 3 steps were exposed to ELisp, so the top-level of >> redisplay could be moved to ELisp. This would allow for example >> `follow-mode` to pick a more appropriate order in which to process the >> windows at step 2. > > follow-mode needs much more than that. If the redisplay toplevel could be hacked in ELisp, follow-mode could call the `update-window-glyph-matrix` on the "main window" of its window-set first, then get the resulting window-end/start and use that to adjust/scroll its next/prev windows, and then call `update-window-glyph-matrix` on them, thus propagating the information in the right direction and avoiding unnecessary redisplay computations. > But if you want to be able to tell redisplay "update only this window > and nothing else", I think it should be easy to accomplish by adding > a single function and no other changes: all you need is to call > 'redisplay' (which is already exposed) after setting the redisplay > flag of a single window. That won't avoid redisplaying the other windows whose `redisplay` bits had been set already for other reasons. I guess we could try to "save the redisplay bit" of other windows/buffers/frames, and restore them afterwards. Also, it would be good to be able to compute the glyph matrices of the various affected windows before we do the actual glass update (especially if we want to handle iteration where some part of the redisplay (e.g. jit-lock, evaluation of mode-lines and menu bars, point moving out of scope forcing a scroll, you name it) causes changes which require recomputing a glyph matrix we just computed). Stefan