From: Eli Zaretskii <eliz@gnu.org>
To: martin rudalics <rudalics@gmx.at>
Cc: enometh@meer.net, 39977@debbugs.gnu.org
Subject: bug#39977: 28.0.50; Unhelpful stack trace
Date: Wed, 18 Mar 2020 21:36:04 +0200 [thread overview]
Message-ID: <835zf1fobf.fsf@gnu.org> (raw)
In-Reply-To: <bc03fa9f-9792-6de8-ff5b-53f4b099296c@gmx.at> (message from martin rudalics on Wed, 18 Mar 2020 19:48:10 +0100)
> Cc: enometh@meer.net, 39977@debbugs.gnu.org
> From: martin rudalics <rudalics@gmx.at>
> 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.
next prev parent reply other threads:[~2020-03-18 19:36 UTC|newest]
Thread overview: 43+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-07 17:43 bug#39977: 28.0.50; Unhelpful stack trace Madhu
2020-03-07 18:50 ` Eli Zaretskii
2020-03-13 9:55 ` Eli Zaretskii
2020-03-13 16:28 ` martin rudalics
2020-03-13 19:43 ` Eli Zaretskii
2020-03-14 8:48 ` martin rudalics
2020-03-14 10:10 ` Eli Zaretskii
2020-03-14 10:37 ` martin rudalics
2020-03-14 18:55 ` martin rudalics
2020-03-14 20:09 ` Eli Zaretskii
2020-03-15 17:49 ` martin rudalics
2020-03-15 18:41 ` Eli Zaretskii
2020-03-16 9:24 ` martin rudalics
2020-03-16 15:33 ` Eli Zaretskii
2020-03-17 9:38 ` martin rudalics
2020-03-17 15:51 ` Eli Zaretskii
2020-03-17 17:31 ` martin rudalics
2020-03-17 17:45 ` Eli Zaretskii
2020-03-17 18:39 ` martin rudalics
2020-03-17 19:41 ` Eli Zaretskii
2020-03-18 9:12 ` martin rudalics
2020-03-18 14:53 ` Eli Zaretskii
2020-03-18 18:48 ` martin rudalics
2020-03-18 19:36 ` Eli Zaretskii [this message]
2020-03-19 8:55 ` martin rudalics
2020-03-19 14:33 ` Eli Zaretskii
2020-03-21 9:32 ` martin rudalics
2020-03-21 13:15 ` Eli Zaretskii
2020-03-22 18:20 ` martin rudalics
2020-03-23 14:48 ` Eli Zaretskii
2020-03-24 9:45 ` martin rudalics
2020-03-28 8:23 ` Eli Zaretskii
2020-03-28 18:38 ` martin rudalics
2020-04-03 16:32 ` martin rudalics
2020-04-10 11:51 ` Madhu
2020-09-30 15:06 ` Lars Ingebrigtsen
2020-09-30 15:31 ` Eli Zaretskii
2020-09-30 17:29 ` martin rudalics
2020-10-01 0:01 ` Lars Ingebrigtsen
2020-10-01 4:37 ` Madhu
2020-03-19 3:48 ` Madhu
2020-03-16 2:42 ` Madhu
2020-03-16 9:25 ` martin rudalics
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=835zf1fobf.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=39977@debbugs.gnu.org \
--cc=enometh@meer.net \
--cc=rudalics@gmx.at \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.