unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
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.





  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

  List information: https://www.gnu.org/software/emacs/

* 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 public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).