Package installation error is ignored despite --debug-init

[bcc32]

If package-installation fails (at least from quelpa recipes, I didn't test other packages), the error is not caught by --debug-init and instead startup proceeds as normal. This seems bad, --debug-init should start the debugger when the package installation encounters an error rather than later down the line when the package fails to load.

For example, I deliberately uninstalled and broke my local copy of evil-evilified-state, then tried starting emacs --debug-init. The error appears in *Messages* but does not trigger the debugger, which only gets tripped when a later step attempts to load the package and fails.

(Spacemacs) --> installing package: evil-evilified-state@spacemacs-bootstrap... [1/1]
Fetcher: file
Source: nil

(Spacemacs) Error: 
An error occurred while installing evil-evilified-state (error: (error Single file evil-evilified-state-2.el does not match package name evil-evilified-state))

Similarly, when use-package fails to find a package to load it does not trigger the debugger despite --debug-init.

[bcc32]

Doing some digging, it appears that errors raised inside condition-case-unless-debug (such as inside configuration-layer//install-package) do not trip the debugger with --debug-init. I don't happen to have an Emacs 29 install handy right now so I'm not immediately sure if this is a regression in Emacs 30.1. Seems surprising.

[fnussbaum]

This indeed seems to be regression in Emacs 30. I've submitted a bug report upstream: https://debbugs.gnu.org/cgi/bugreport.cgi?bug=76949.

[fnussbaum]

@bcc32 How should we proceed here? I'm considering the following alternatives:

1. Make --debug-init set debug-on-error in Spacemacs. We could either adhere to (and thus ignore the errors in) debug-ignored-errors; or try to save its value, set it to nil, and restore it later, which Emacs used to do, see also this Emacs bug (note that handler-bind was introduced for --debug-init to properly fix this bug).
   If we don't set debug-ignored-errors to nil during startup by default, users might have to set it themselves in dotspacemacs/user-init or early-init.el for debugging purposes (or we provide another startup option that does that...). However, I'm not sure how often one actually needs to debug errors occuring during startup that are in the default value of debug-ignored-errors---at least I've never needed this.
2. Tell users to obtain backtraces by adding (setq debug-on-error t) to dotspacemacs/user-init (and, if necessary, additionally (setq debug-ignored-errors nil)).

[bcc32]

I would rather not hack around --debug-init in Spacemacs, I think.
Diverging from built-in behavior is a sure-fire way to surprise users.

I think for the case where some error is being suppressed by
condition-case-unless-debug or with-demoted-errors (which in Emacs
30 no longer enters the debugger when requested by --debug-init), we
should perhaps just leave it be. Perhaps we could audit the existing
callsites in Spacemacs and see if any of them would benefit from not
using those macros; otherwise, we might just close this issue.

[fnussbaum]

I would rather not hack around --debug-init in Spacemacs, I think.

I tend to agree.

Perhaps we could audit the existing
callsites in Spacemacs and see if any of them would benefit from not
using those macros; otherwise, we might just close this issue.

I think if we clearly document that one needs to use debug-on-error to obtain backtraces in many cases, it should be fine to even introduce more callsites, and thus catch a larger share of errors on startup.

[smile13241324]

If we do not provide a workaround I will close this as an emacs bug.