bug#39977: 28.0.50; Unhelpful stack trace

[martin rudalics <rudalics@gmx.at>]

 >> I'm afraid that we already might mishandle some of those simple cases.
 >
 > That just makes my point stronger, doesn't it?

Not really.  It's easy for delete_frame to refuse deleting a frame right
at the beginning.  But once it has accepted a deletion, it might become
hard to deal with all the consequences.

 >>   > The problem is how to do this without breaking legitimate code.  For
 >>   > example, changing the window configuration temporarily, then changing
 >>   > it back is quite legitimate,
 >>
 >> Right in the middle of redisplay, while constructing the mode line or
 >> the title format?
 >
 > Why not?  As long as things are back as they were by the time :eval
 > returns, I see no reason to disallow such code.

Such a change in the window configuration would take place in a state
where certain variables have temporary settings only.  Selected frame,
selected window and current buffer have been set by redisplay in a fast,
improvised manner.  I would never trust the outcome of save_window_save
or 'set-window-configuration' in such a state.

 > No, they are there in cases where we simply don't know how to
 > continue.

If that's the reason, then SELECTED_FRAME can easily set selected_frame
to some live frame and continue.

martin