unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: 65267@debbugs.gnu.org, stepnem@smrk.net, npostavs@users.sourceforge.net
Subject: bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken
Date: Thu, 17 Aug 2023 12:31:48 +0300	[thread overview]
Message-ID: <83v8de581n.fsf@gnu.org> (raw)
In-Reply-To: <jwvr0o6pww4.fsf-monnier+emacs@gnu.org> (message from Stefan Monnier on Sun, 13 Aug 2023 15:47:33 -0400)

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  65267@debbugs.gnu.org,
>     Noam Postavsky <npostavs@users.sourceforge.net>
> Date: Sun, 13 Aug 2023 15:47:33 -0400
> 
> [ Added Noam, since we're mentioning a problem linked to yasnippet.el.  ]
> 
> >> Yeah, it's wrong, but I'm not sure how to fix it:
> >> `--debug-init` needs to change the value of `debug-ignored-errors` while
> >> `init.el` is executed,
> >
> > FWIW, I'm sure I'm missing something, but the above is far from obvious
> > to me.  Why does --debug-init need to muck with debug-ignored-errors at
> > all?  debug-ignored-errors usually/mostly contains errors unlikely to
> > occur during startup,
> 
> "unlikely" doesn't mean they should be ignored: `debug-ignored-errors`
> is for errors which should not bring up a debugger if they occur in
> interactive use, but they're still errors, and if they occur during
> `init.el` they are definitely not ignored: they stop the processing of
> `init.el`.  So when debugging init errors, we *should* bring up the
> debugger for them.
> 
> >> Maybe we should introduce a new `inhibit-debug-ignored-errors` which we
> >> could let-bind while loading `init.el` without having to modify
> >> `debug-ignored-errors` itself?
> >
> > If ignoring debug-ignored-errors during startup is really necessary,
> > that sounds like a possibly cleaner way, indeed
> 
> ..
> 
> > (albeit introducing yet another form to ignore another form ignoring
> > errors...).
> 
> Yes, that's what's making me hesitate.

What about the minor changes below?  They do seem to yield the
expected results in the original recipe.  The idea is to detect the
situation where the init file _added_ to the value of
debug-ignored-errors, and re-add the additions after loading the init
file.

diff --git a/lisp/startup.el b/lisp/startup.el
index 43d6bf7..4d0e59b 100644
--- a/lisp/startup.el
+++ b/lisp/startup.el
@@ -1023,6 +1023,7 @@ startup--load-user-init-file
          ;; Use (startup--witness) instead of nil, so we can detect when the
          ;; init files set `debug-ignored-errors' to nil.
          (if init-file-debug '(startup--witness) debug-ignored-errors))
+        (d-i-e-standard debug-ignored-errors)
         ;; The init file might contain byte-code with embedded NULs,
         ;; which can cause problems when read back, so disable nul
         ;; byte detection.  (Bug#52554)
@@ -1111,8 +1112,16 @@ startup--load-user-init-file
 
       ;; If we can tell that the init file altered debug-on-error,
       ;; arrange to preserve the value that it set up.
-      (or (eq debug-ignored-errors d-i-e-initial)
-          (setq d-i-e-from-init-file (list debug-ignored-errors)))
+      (unless (eq debug-ignored-errors d-i-e-initial)
+        (if (memq 'startup--witness debug-ignored-errors)
+            ;; The init file wants to add errors to the standard
+            ;; value, so we need to emulate that.
+            (setq d-i-e-from-init-file
+                  (list (append d-i-e-standard
+                                (remq 'startup--witness
+                                      debug-ignored-errors))))
+          ;; The init file _replaces_ the standard value.
+          (setq d-i-e-from-init-file (list debug-ignored-errors))))
       (or (eq debug-on-error debug-on-error-initial)
           (setq debug-on-error-should-be-set t
                 debug-on-error-from-init-file debug-on-error)))





  parent reply	other threads:[~2023-08-17  9:31 UTC|newest]

Thread overview: 32+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-08-13  7:54 bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken Štěpán Němec
2023-08-13  9:49 ` Eli Zaretskii
2023-08-13 10:03   ` Štěpán Němec
2023-08-13 10:12     ` Eli Zaretskii
2023-08-13 10:24       ` Štěpán Němec
2023-08-13 12:38         ` Eli Zaretskii
2023-08-13 16:19 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-13 16:32   ` Eli Zaretskii
2023-08-13 17:08   ` Štěpán Němec
2023-08-13 17:52     ` Eli Zaretskii
     [not found]       ` <20230813203525+0200.956511-stepnem@smrk.net>
2023-08-13 19:05         ` Eli Zaretskii
2023-08-13 19:47     ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
     [not found]       ` <20230813223458+0200.843367-stepnem@smrk.net>
2023-08-14  2:26         ` Eli Zaretskii
2023-08-14  6:48           ` Štěpán Němec
2023-08-17  9:31       ` Eli Zaretskii [this message]
2023-08-17 12:55         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-08-17 13:28           ` Eli Zaretskii
2023-08-17 14:16             ` Štěpán Němec
2023-08-17 14:31               ` Eli Zaretskii
2023-08-17 14:36                 ` Eli Zaretskii
2023-08-17 15:52                 ` bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken, " Štěpán Němec
2023-08-17 16:05                   ` Eli Zaretskii
2023-08-17 16:29                     ` Štěpán Němec
2023-08-17 17:58                       ` Eli Zaretskii
2023-08-17 18:15                         ` Štěpán Němec
2023-08-17 18:36                           ` Eli Zaretskii
2023-08-17 17:15                   ` Gregory Heytings
2023-08-17 17:27                     ` Štěpán Němec
2023-08-17 18:07                       ` Gregory Heytings
2023-08-17 18:20                         ` Štěpán Němec
2023-08-17 18:31                           ` Gregory Heytings
2023-08-17 18:36                             ` Štěpán Němec

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=83v8de581n.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=65267@debbugs.gnu.org \
    --cc=monnier@iro.umontreal.ca \
    --cc=npostavs@users.sourceforge.net \
    --cc=stepnem@smrk.net \
    /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).