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

[Stefan Monnier via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>]

>> 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