bug#39977: 28.0.50; Unhelpful stack trace

[Eli Zaretskii <eliz@gnu.org>]

> Cc: enometh@meer.net, 39977@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> Date: Thu, 19 Mar 2020 09:55:07 +0100
> 
>  >> We already disallow deleting the last live or visible frame and the last
>  >> window on a frame.
>  >
>  > Those situations are easy to detect, so we do that.
> 
> For some value of easy.

Relatively easy.

>  > You are now
>  > proposing something more sophisticated than that, and I'm afraid that
>  > doing so is not as straightforward as in those few simple cases we
>  > already handle.
> 
> I'm afraid that we already might mishandle some of those simple cases.

That just makes my point stronger, doesn't it?

>  >> So the redisplay code, whenever it runs Lisp in between, could
>  >> simply set a boolean that will disallow deleting any window or frame
>  >> as well as setting the window configuration and other dangerous
>  >> operations that implicitly might kill a window or a buffer.
>  >
>  > 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.

>  > so summarily disallowing such actions is
>  > too drastic and will be hard to justify.
> [...]
>  > All we need to do is avoid crashing and keeping the display
>  > up-to-date; any other outcome: error messages, code that doesn't do
>  > what the author expected/intended, and any other annoyance -- are
>  > completely fine, because whoever writes such nasty code will learn a
>  > lesson.
> 
> Hmmm...  I thought we have all those emacs_abort instances to ease
> debugging.

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