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#63988: 30.0.50; Recent header line format changes cause spin/seg fault with format-mode-line Date: Sat, 10 Jun 2023 20:42:25 +0300 Message-ID: <83h6rfz01q.fsf@gnu.org> References: <831qij24qm.fsf@gnu.org> <83wn0bzoeb.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26811"; mail-complaints-to="usenet@ciao.gmane.io" Cc: me@eshelyaron.com, 63988@debbugs.gnu.org, aaronjensen@gmail.com To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Jun 10 19:43:21 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 1q82cS-0006pe-FB for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 10 Jun 2023 19:43:20 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q82cC-0004dx-Ct; Sat, 10 Jun 2023 13:43: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 1q82cA-0004dm-Lz for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 13:43: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 1q82cA-0003Eh-Du for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 13:43:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1q82cA-0002nh-9A for bug-gnu-emacs@gnu.org; Sat, 10 Jun 2023 13:43: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, 10 Jun 2023 17:43:02 +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.168641894510710 (code B ref 63988); Sat, 10 Jun 2023 17:43:02 +0000 Original-Received: (at 63988) by debbugs.gnu.org; 10 Jun 2023 17:42:25 +0000 Original-Received: from localhost ([127.0.0.1]:36213 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q82bY-0002me-Tc for submit@debbugs.gnu.org; Sat, 10 Jun 2023 13:42:25 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:58776) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1q82bV-0002mP-Qt for 63988@debbugs.gnu.org; Sat, 10 Jun 2023 13:42: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 1q82bP-00034z-J7; Sat, 10 Jun 2023 13:42: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=VjPvYXiUnwL6cjbN+6Mw2jBU1EuqJeg5OMu2C6/USPg=; b=rn6q3h6mUXKS I6GGImOqYvA1PS1eVp0MrkI1lXRvx/I6lsBizZtD8fbHcDPst7gFOU+jUXqVd8T+x5XAIqTsvGIPW 68ecQ53/iRlyTihJ8l4FT9KoHgKMyFSgyh8Pj5eMOua6df1QSbJXK8NqkDgp6W3Ps6VOZEvIJAqRe fO9u6jAGep5ArVFNwqa6SBRQP/fatGKSQT0CVSHNxDYf6S8RLmZRhJ659udZVbSbL3vQh84+X159/ wwX1+0OrvH7mj2y56/YBL2mMeIAUcnNOnqDP+L2/VtO3hmfe5wlPF7ajyhtzO+bCJ+TvlJmETy3mC RFnYnThwI4oKqQkSS6EOUQ==; 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 1q82bO-0003sN-U7; Sat, 10 Jun 2023 13:42:15 -0400 In-Reply-To: (message from Stefan Monnier on Sat, 10 Jun 2023 12:16:45 -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:263230 Archived-At: > From: Stefan Monnier > Cc: aaronjensen@gmail.com, Eshel Yaron , > 63988@debbugs.gnu.org > Date: Sat, 10 Jun 2023 12:16:45 -0400 > > >> It causes infinite recursion, since format-mode-line also calls > >> window_wants_header_line (indirectly). > > 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. 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. And the Lisp code called from :eval could easily call some primitive that uses the display code, for example vertical-motion or window-text-pixel-size or something else. Going over all those places and making sure init_iterator will not call window_wants_header_line in those cases is not my idea of fun, even if it is practical to discern between the cases where it does and doesn't need that. > > However, I wonder whether we should rethink this minor feature. > > Perhaps this minor convenience is not worth the complications? > > IIUC This is talking about commit > 4f66cbbfe520ee31ef26676e09a926217d9736fe which extends the special > treatment of a nil `header-line-format` to also hide the header line > when its value is "equivalent" to nil. > > 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. Once again: the display code is many times called for purposes other than display, and in at least some of those cases it does need to know whether there is a header-line, because the layout and the metrics of the text on display depend on that. So the question of when to record the fact of header-line existence for a particular window -- that question doesn't have an easy answer. It is easy to compute that at the beginning of redisplay_window, but what about the following scenario in some Lisp program: . do some calculation that affects header-line existence . call window-text-pixel-size and its many variations? Are we going to sprinkle the code with calls to a function that calculates the header-line and records the result somewhere (perhaps in a window) before each call to init_iterator and start_display, and if so, how to avoid potential recursion like the one in this case? Or maybe we want to use the variable-watcher feature to do that whenever header-line-format is modified? That is also far from being fun, and could cause performance degradation, as some people, I hear, use header-line to display the mode-line information. 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. Let's admit it: the current Emacs display code was not designed to support this, so it's a little wonder we face an uphill battle. And maybe we should just admit defeat and say we cannot support it until and unless the display engine is redesigned with this goal in mind.