[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: |
Thu, 19 Mar 2020 16:33:53 +0200 |
> 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.
- bug#39977: 28.0.50; Unhelpful stack trace, (continued)
- bug#39977: 28.0.50; Unhelpful stack trace, Eli Zaretskii, 2020/03/17
- bug#39977: 28.0.50; Unhelpful stack trace, martin rudalics, 2020/03/17
- bug#39977: 28.0.50; Unhelpful stack trace, Eli Zaretskii, 2020/03/17
- bug#39977: 28.0.50; Unhelpful stack trace, martin rudalics, 2020/03/17
- bug#39977: 28.0.50; Unhelpful stack trace, Eli Zaretskii, 2020/03/17
- bug#39977: 28.0.50; Unhelpful stack trace, martin rudalics, 2020/03/18
- bug#39977: 28.0.50; Unhelpful stack trace, Eli Zaretskii, 2020/03/18
- bug#39977: 28.0.50; Unhelpful stack trace, martin rudalics, 2020/03/18
- bug#39977: 28.0.50; Unhelpful stack trace, Eli Zaretskii, 2020/03/18
- bug#39977: 28.0.50; Unhelpful stack trace, martin rudalics, 2020/03/19
- bug#39977: 28.0.50; Unhelpful stack trace,
Eli Zaretskii <=
- bug#39977: 28.0.50; Unhelpful stack trace, martin rudalics, 2020/03/21
- bug#39977: 28.0.50; Unhelpful stack trace, Eli Zaretskii, 2020/03/21
- bug#39977: 28.0.50; Unhelpful stack trace, martin rudalics, 2020/03/22
- bug#39977: 28.0.50; Unhelpful stack trace, Eli Zaretskii, 2020/03/23
- bug#39977: 28.0.50; Unhelpful stack trace, martin rudalics, 2020/03/24
- bug#39977: 28.0.50; Unhelpful stack trace, Eli Zaretskii, 2020/03/28
- bug#39977: 28.0.50; Unhelpful stack trace, martin rudalics, 2020/03/29
- bug#39977: 28.0.50; Unhelpful stack trace, Madhu, 2020/03/18
- bug#39977: 28.0.50; Unhelpful stack trace, Madhu, 2020/03/15
- bug#39977: 28.0.50; Unhelpful stack trace, martin rudalics, 2020/03/16