bug#39977: 28.0.50; Unhelpful stack trace

[martin rudalics <rudalics@gmx.at>]

 > I'm sorry, I think I no longer know what we are discussing.

For me the present abort is just another instance of Bug#29726 where you
said:

   The reason for the crash is that the ':eval' form which you have on
   the header-line can delete the frame whose header-line Emacs is
   redrawing!  The Lisp-level backtrace below shows how delete-frame is
   called from your code; hopefully, this backtrace will allow you to fix
   your code so it doesn't do such nonsensical things.

Only that in the case at hand 'delete-frame' does not try to delete the
frame the display engine is working on and so your fix for Bug#29726
won't catch it.  Rather, the frame that gets deleted is the frame that
was selected before the display engine started to process the :eval
form.  When, after processing the :eval form and the containing mode
line or title bar format, the display engine wants to restore the
previously selected frame, it sets selected_frame to a dead frame.  And
the next attempt to use selected_frame via SELECTED_FRAME results in the
abort.

 > Feel free
 > to fix this (whatever it is) as you see fit.

The longer I'm looking into this, the more I think that we should be
much more restrictive wrt what an :eval form in mode line or title name
processing should be allowed to do.  Tab bars could provide even more
confusion.  I think we should disallow any such :eval to kill buffers
and delete windows or frames at the very least.

Maybe it should be also disallowed to select a window or frame or
whatever the display engine tries to restore after processing these
forms.  Such selections would be usually undone anyway by the display
engine.  Probably, we should disallow such :eval forms to modify
"anything" at all but I have no idea how to do that.

martin