bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39977: 28.0.50; Unhelpful stack trace


From: Eli Zaretskii
Subject: bug#39977: 28.0.50; Unhelpful stack trace
Date: Wed, 18 Mar 2020 21:36:04 +0200

> Cc: address@hidden, address@hidden
> From: martin rudalics <address@hidden>
> Date: Wed, 18 Mar 2020 19:48:10 +0100
> 
>  > I'm not sure we can detect these actions reliably, as Lisp code can be
>  > very complex.  I think we can only handle the consequences of those
>  > actions.
> 
> 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.  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.

> 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, so summarily disallowing such actions is
too drastic and will be hard to justify.

>  > Which is why I proposed to deal with that in SELECTED_FRAME
>  > (we could, of course, find some other place where the disastrous
>  > results of such code can be detected).
> 
> SELECTED_FRAME does not necessarily have to abort.  It could return some
> other live frame, maybe selecting it on-the-fly, in the hope that the
> configuration stabilizes sooner or later.  But this doesn't help with
> the fact that such an :eval can do a lot more nasty things like deleting
> windows or killing buffers.

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.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]