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 20:11:24 +0300 Message-ID: <83mszv93yb.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> <87ttu4gnpt.fsf@localhost> <83351o9m6h.fsf@gnu.org> <87ilakgmjo.fsf@localhost> <83pm4r9apt.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="18102"; 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 Sun Jul 16 19:12:23 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 1qL5IE-0004YR-3N for geb-bug-gnu-emacs@m.gmane-mx.org; Sun, 16 Jul 2023 19:12:22 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qL5Hw-0001dv-Lx; Sun, 16 Jul 2023 13:12: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 1qL5Hv-0001dl-4h for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 13:12:03 -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 1qL5Hu-00040G-Qd for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 13:12:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qL5Hu-0004NN-Ae for bug-gnu-emacs@gnu.org; Sun, 16 Jul 2023 13:12: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: Sun, 16 Jul 2023 17:12: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.168952748516775 (code B ref 64596); Sun, 16 Jul 2023 17:12:02 +0000 Original-Received: (at 64596) by debbugs.gnu.org; 16 Jul 2023 17:11:25 +0000 Original-Received: from localhost ([127.0.0.1]:48483 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qL5HJ-0004MU-AW for submit@debbugs.gnu.org; Sun, 16 Jul 2023 13:11:25 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40052) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qL5HF-0004MF-MC for 64596@debbugs.gnu.org; Sun, 16 Jul 2023 13:11:23 -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 1qL5H9-0003B1-6V; Sun, 16 Jul 2023 13:11:15 -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=za777tUu9XN7z6MU2nJrtc+W3AqV2/F/R3aG40buUGQ=; b=huFp+H8EDyJt rGxjChgH8H994kDldky5ktzJSBHmmJD+qZNLbMQP3fWYUghcrWqkGr2BUU6nOXqSN5smO0UY6HGM8 l4TuJHwNaQwgX3Ck2IRrR6xi99nRhT81VhAhg+t2gmYHP6UtCwHnOJDy16n96RlhcjhMspmM94WWM VcImLc+X/s6we6t1FYOtqNS8A3NoKjjkbgtLGYrI7Cr3o8WfS1ygOCorI+8cChA8Ic3SbaRHMdrLk W4lu7luXoES/OU45O5FYKem1h283xa+dLiZbLuw17V2IyDwfpap2SQOdRnWQ1YVG7tgL3GTRfbg5d fxgd5/PO5IpeeopaSpczhg==; 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 1qL5Gu-0006Jt-Ju; Sun, 16 Jul 2023 13:11:14 -0400 In-Reply-To: (message from Stefan Monnier on Sun, 16 Jul 2023 12:44:08 -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:265353 Archived-At: > From: Stefan Monnier > Cc: yantar92@posteo.net, 64596@debbugs.gnu.org > Date: Sun, 16 Jul 2023 12:44:08 -0400 > > > 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. Because fset_redisplay does this: void fset_redisplay (struct frame *f) { redisplay_other_windows (); f->redisplay = true; } and redisplay_other_windows sets windows_or_buffers_changed, which then causes consider_all_windows_p to be true upon the next redisplay cycle: consider_all_windows_p = (update_mode_lines || windows_or_buffers_changed); > 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. Yes, it will: when a window is redisplayed by redisplay_window, its redisplay flag is reset, and it will not be redisplayed during this cycle. So if you have a way to redisplay a single window, you can do that in any order you want, one window at a time, and those windows which you redisplayed in this way will not be redisplayed until the next cycle. As for update-window-glyph-matrix, I don't see why that would help, because updating the matrix without calling update_window fairly soon after that will not produce the effect that you want. > I guess we could try to "save the redisplay bit" of other > windows/buffers/frames, and restore them afterwards. What for? > 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). Sounds like an unnecessary complication to me, and for some situations I'm not even sure how you can handle them, unless you thoroughly redesign the display code. IOW, this is not just a matter of exposing a small number of functions to Lisp, IMO.