GNU bug report logs - #65267
30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken

Previous Next

Full log

View this message in rfc822 format

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Štěpán Němec <stepnem <at> smrk.net>
Cc: 65267 <at> debbugs.gnu.org, Eli Zaretskii <eliz <at> gnu.org>, Noam Postavsky <npostavs <at> users.sourceforge.net>
Subject: bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken
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.

>> We could document that modifying debug-ignored-errors only works
>> reliably if done from after-init-hook.  WDYT?
>
> Pushing the breakage downstream... would mean packages like yasnippet
> would have to adapt, among other things.  Not the end of the world, I
> guess, but I still don't understand why the breakage (or "change in
> behavior", if you prefer) is necessary or desired.

Hmm... thanks for pointing out that left-over thingy in `yasnippet.el`
which should have been removed as part of:

    commit 175e0a3a102c22c0c99d8d00ecf8bc8539a4e593
    Author: João Távora <joaotavora <at> gmail.com>
    Date:   Mon Nov 17 11:27:30 2014 +0000
    
        Clean up previous change
        
        * yasnippet.el: Update comment.
        (yas--protection-violation): Removed.
        (yas--on-protection-overlay-modification): Simplified.
        (yas--post-command-handler): No longer reference
        `yas--protection-violation'

I pushed a commit to clean this up to the `scratch/yasnippet` branch of
elpa.git.


        Stefan

Previous Next

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