GNU bug report logs - #39977
28.0.50; Unhelpful stack trace

Previous Next

Package: emacs;

Reported by: Madhu <enometh <at> meer.net>

Date: Sat, 7 Mar 2020 18:09:01 UTC

Severity: normal

Tags: fixed

Found in version 28.0.50

Fixed in version 28.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: martin rudalics <rudalics <at> gmx.at>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: enometh <at> meer.net, 39977 <at> debbugs.gnu.org
Subject: bug#39977: 28.0.50; Unhelpful stack trace
Date: Wed, 18 Mar 2020 19:48:10 +0100
> So we are talking about :eval in mode-line-format (and similar
> variables)?

I am but I might be wrong.  Maybe Madhu can tell us where that window
quitting operation is issued.

> 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.  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.

> 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.

martin





This bug report was last modified 4 years and 285 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.