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

[Eli Zaretskii]

> Cc: 63988@debbugs.gnu.org
> Date: Sat, 10 Jun 2023 09:47:29 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > From: Aaron Jensen <aaronjensen@gmail.com>
> > Date: Fri, 09 Jun 2023 21:09:45 -0400
> > 
> > 
> > (setq header-line-format '(:eval (format-mode-line "")))
> > 
> > This causes Emacs to spin as of commit:
> > 4f66cbbfe520ee31ef26676e09a926217d9736fe
> > 
> > After some time, it will segfault.
> 
> It causes infinite recursion, since format-mode-line also calls
> window_wants_header_line (indirectly).
> 
> But what is the purpose of such a strange (to use a civilized word)
> setting of header-line-format?  Why do you need :eval at all in this
> case?
> 
> IOW, why not say "don't do that" and be done?

For now, I installed a semi-kludgey fix.

However, I wonder whether we should rethink this minor feature.
Perhaps this minor convenience is not worth the complications?
window_wants_header_line is called in many places, all of which can
now evaluate arbitrary Lisp, and all of which can now GC.  I've
audited the various callers, and didn't see anything obvious that
could cause problems with calling Lisp or GC in those places, but I
could have missed something.

This is actually a general issue with Emacs: we keep piling one minor
feature upon another, and don't always reflect on the hard-to-maintain
monster that creates.  We have already a couple of areas in the code
base where we are afraid of making changes, because we don't have a
good understanding of the complicated state variables there.  Maybe we
should reject such minor features instead of keeping doing what we
have been doing?

So maybe we should declare this feature a failed experiment and remove
it?