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#63988: 30.0.50; Recent header line format changes cause spin/seg fault with format-mode-line Date: Sat, 10 Jun 2023 15:11:46 -0400 Message-ID: References: <831qij24qm.fsf@gnu.org> <83wn0bzoeb.fsf@gnu.org> <83h6rfz01q.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="4645"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: me@eshelyaron.com, 63988@debbugs.gnu.org, aaronjensen@gmail.com To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 10 21:13:24 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 1q841b-00013U-NC for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Jun 2023 21:13:24 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q841I-00019l-9x; Sat, 10 Jun 2023 15:13: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 1q841G-00019F-AQ for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 15:13:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1q841G-0002SB-2E for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 15:13:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q841F-0005IH-KV for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 15:13: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: Sat, 10 Jun 2023 19:13:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 63988 X-GNU-PR-Package: emacs Original-Received: via spool by 63988-submit@debbugs.gnu.org id=B63988.168642433220289 (code B ref 63988); Sat, 10 Jun 2023 19:13:01 +0000 Original-Received: (at 63988) by debbugs.gnu.org; 10 Jun 2023 19:12:12 +0000 Original-Received: from localhost ([127.0.0.1]:36325 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q840R-0005HB-P6 for submit@debbugs.gnu.org; Sat, 10 Jun 2023 15:12:12 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:21780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q840M-0005Gl-Kt for 63988@debbugs.gnu.org; Sat, 10 Jun 2023 15:12:09 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 5CDDD440A32; Sat, 10 Jun 2023 15:12:01 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id 8A0F4440BEF; Sat, 10 Jun 2023 15:11:55 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1686424315; bh=xSXXp70pKBAWno2RqVmhjDHv9tuRm6ddzz7UIr+Hbe0=; h=From:To:Cc:Subject:In-Reply-To:References:Date:From; b=odrdJU/XuthF0eyBtUl03QbABn3QAF//STsSrIJV+leY7AY72TGyMzh9+ZOwOyOIl 0vtI6ZGNvYMMtbFgW2n3IHlDxNwPHYrV/nU37kNyb+X2e1rVNapxUCVnCPEPzuzHde Fh8BuG4oTCG8kGVli9oCMVaEcBb+MFsWb2S5CILYYoM5FfEwBcbvDyFKafP3KFHZOa ADSWbMYhk3n1q4h3mmDeAbJ1AjrMUU7tq7u9PmzxN9SIV8uYi8kf/2EuLE4sOlrK+d SFd4BIRNS/0RmFp6Bnc5n6p5NXIMeyvT+9rXn+WG2boGFXi3dmw3Ksssg5IlZOBwow f+s+oW8ZsX1bw== Original-Received: from pastel (76-10-180-239.dsl.teksavvy.com [76.10.180.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 5A8241203C4; Sat, 10 Jun 2023 15:11:55 -0400 (EDT) In-Reply-To: <83h6rfz01q.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 10 Jun 2023 20:42:25 +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:263234 Archived-At: >> I wonder why `format-mode-line` calls `window_wants_header_line`. >> Is there a deep technical reason, or just an accident of how we >> currently implement the feature? > format-mode-line calls init_iterator (because the formatting is done > by display code), and init_iterator calls window_wants_header_line > because it needs to know the general layout of the window up front. Ah, I see. > We could introduce some knobs to perhaps avoid this in the particular > case of format-mode-line, but the :eval form in header-line-format can > call any Lisp, not necessarily format-mode-line. There's no doubt that in the most general case the arbitrary ELisp code run from `header-line-format` can cause enough redisplay work to require computation of `header-line-format`, indeed. >> In the past I've wished for a non-nil mode-line that is not displayed >> because it's equivalent to nil, so I think the feature makes sense, but >> I agree it's not super important. Maybe if we want to make it work >> well, the better solution is to memoize the computation of >> (format-mode-line header-line-format) so that it's called at most once >> per redisplay? > > That is possible, and I thought about it as well, but it isn't easy. Agreed. I can see two benefits: - try and handle the recursion by marking the header-line as "wanted" while we compute it so recursive calls to `window_wants_header_line` just return `true` without actually doing the work recursively. - try and reduce the cost of re-computing it every time. But obviously, like all memoization/caching schemes, the hard part is to figure out how/when to flush the obsolete info. It's definitely not easy. > Bottom line: this sounds like a minor convenience feature that causes > major headaches to implement, because once you allow evaluation of > arbitrary Lisp, all bets are basically off. I can't remember the details of when I wanted a non-nil `mode-line-format` to be equivalent to nil, but IIRC I worked around the problem with ad-hoc hooks at various places to set/reset `mode-line-format` to nil and back according to whether a mode line should be displayed. Still, I can see cases where we may want a header-line that's only displayed in some specific *windows*, so the buffer's value can't be nil (for that window) but shouldn't be non-nil (for the other windows displaying that buffer). In the absence of the problematic commit we can't handle such cases. But we've lived with such a limitation for almost 40 years, so I'm fine with removing that feature rather than trying to make it work. We'll want to ad some comments in the code to try and avoid someone else go through the same process, tho. Stefan