bug#63988: 30.0.50; Recent header line format changes cause spin/seg fault with format-mode-line

[Aaron Jensen <aaronjensen@gmail.com>]

On Sat, Jun 10, 2023 at 1:42 PM Eli Zaretskii <eliz@gnu.org> wrote:
>
> > From: Stefan Monnier <monnier@iro.umontreal.ca>
> > Cc: aaronjensen@gmail.com,  Eshel Yaron <me@eshelyaron.com>,
> >   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.

I'm personally fine with this. I also wonder if the initial use-case
that led to this feature could be handled instead by controlling the
header line format when whatever factor changes that would determine
whether or not to display a header line. I know I have to do this with
mode line now that my mode line is typically nil, but I use it
sometimes to display things like number of matches.

Aaron