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

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

[Štěpán Němec]

sh(1) reproduction recipe:

--8<--
initdir=$(mktemp -d)

echo "(add-to-list 'debug-ignored-errors 'my-error)" >"$initdir"/init.el
emacs --debug-init --init-dir="$initdir" \
      --eval '(message "%S" debug-ignored-errors)'

rm -rf "$initdir"
--8<--

In the emacs thus started, the value of `debug-ignored-errors' is
"(my-error startup--witness)" instead of `my-error' added to
the default ignored error symbol list.

(It works as expected *without* --debug-init.)


In GNU Emacs 30.0.50 (build 3, x86_64-pc-linux-gnu, cairo version
 1.17.8) of 2023-08-13 built on tipi
Repository revision: 6d58007bb05b92d5bafb91631df8fef8d99e6722
                     ^
[that's just 08bf8533bb1d with some unrelated stuff on top, sorry about that]
Repository branch: use
Windowing system distributor 'The X.Org Foundation', version 11.0.12101008
System Description: Arch Linux

Configured using:
 'configure --config-cache --without-x-toolkit'

Configured features:
ACL CAIRO DBUS FREETYPE GIF GLIB GMP GNUTLS GPM GSETTINGS HARFBUZZ JPEG
JSON LCMS2 LIBOTF LIBSYSTEMD LIBXML2 M17N_FLT MODULES NOTIFY INOTIFY
OLDXMENU PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TREE_SITTER
WEBP X11 XDBE XIM XINPUT2 XPM ZLIB

Important settings:
  value of $LC_MESSAGES: 
  value of $LANG: en_US.UTF-8
  value of $XMODIFIERS: @im=fcitx
  locale-coding-system: utf-8-unix

Major mode: Help

Minor modes in effect:
  tooltip-mode: t
  global-eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  file-name-shadow-mode: t
  isearch-fold-quotes-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  buffer-read-only: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media puny dired
dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg rfc6068
epg-config gnus-util text-property-search time-date subr-x mm-decode
mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader
sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
cl-extra pp cl-print byte-opt gv bytecomp byte-compile debug backtrace
find-func thingatpt help-fns radix-tree help-mode cl-loaddefs cl-lib rmc
iso-transl tooltip cconv eldoc paren electric uniquify ediff-hook
vc-hooks lisp-float-type elisp-mode mwheel term/x-win x-win
term/common-win x-dnd touch-screen tool-bar dnd fontset image regexp-opt
fringe tabulated-list replace newcomment text-mode lisp-mode prog-mode
register page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer nadvice seq simple cl-generic indonesian philippine
cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao
korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech
european ethiopic indian cyrillic chinese composite emoji-zwj charscript
charprop case-table epa-hook jka-cmpr-hook help abbrev obarray oclosure
cl-preloaded button loaddefs theme-loaddefs faces cus-face macroexp
files window text-properties overlay sha1 md5 base64 format env
code-pages mule custom widget keymap hashtable-print-readable backquote
threads dbusbind inotify lcms2 dynamic-setting system-font-setting
font-render-setting cairo xinput2 x multi-tty move-toolbar
make-network-process emacs)

Memory information:
((conses 16 55621 13813) (symbols 48 6384 0) (strings 32 18969 1832)
 (string-bytes 1 511550) (vectors 16 12190)
 (vector-slots 8 168978 11702) (floats 8 45 36) (intervals 56 405 0)
 (buffers 992 12))

-- 
Štěpán

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

[Eli Zaretskii]

> Cc: Stefan Monnier <monnier@iro.umontreal.ca>
> From: Štěpán Němec
>  <stepnem@smrk.net>
> Date: Sun, 13 Aug 2023 09:54:29 +0200
> 
> 
> sh(1) reproduction recipe:
> 
> --8<--
> initdir=$(mktemp -d)
> 
> echo "(add-to-list 'debug-ignored-errors 'my-error)" >"$initdir"/init.el
> emacs --debug-init --init-dir="$initdir" \
>       --eval '(message "%S" debug-ignored-errors)'
> 
> rm -rf "$initdir"
> --8<--
> 
> In the emacs thus started, the value of `debug-ignored-errors' is
> "(my-error startup--witness)" instead of `my-error' added to
> the default ignored error symbol list.

I believe this is a feature: when the user says --debug-init, they
need to be shown all the errors raised during startup; hiding some of
the errors was a misfeature in previous versions of Emacs, now fixed.

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

[Štěpán Němec]

On Sun, 13 Aug 2023 12:49:42 +0300
Eli Zaretskii wrote:

>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>
>> From: Štěpán Němec
>>  <stepnem@smrk.net>
>> Date: Sun, 13 Aug 2023 09:54:29 +0200
>> 
>> 
>> sh(1) reproduction recipe:
>> 
>> --8<--
>> initdir=$(mktemp -d)
>> 
>> echo "(add-to-list 'debug-ignored-errors 'my-error)" >"$initdir"/init.el
>> emacs --debug-init --init-dir="$initdir" \
>>       --eval '(message "%S" debug-ignored-errors)'
>> 
>> rm -rf "$initdir"
>> --8<--
>> 
>> In the emacs thus started, the value of `debug-ignored-errors' is
>> "(my-error startup--witness)" instead of `my-error' added to
>> the default ignored error symbol list.
>
> I believe this is a feature:

Here's hoping it isn't.

> when the user says --debug-init, they need to be shown all the errors
> raised during startup; hiding some of the errors was a misfeature in
> previous versions of Emacs, now fixed.

That would seem OK to me.  The problem is that, as it is now, this
breaks normal Emacs usage of anyone who starts with --debug-init and
happens to modify `debug-ignored-errors' as part of their
initialization.

Note that it might not even be user-intentional/explicit modification,
e.g., I noticed the problem because I load yasnippet from my init file,
and yasnippet adds a custom regexp to debug-ignored-errors; so now I end
up with bogus debug-ignored-errors value, which is further aggravated by
the fact that I normally run with debug-on-errors set, so, for example,
I now end up in the debugger whenever I press C-n at the end of buffer
(until I manually restore debug-ignored-errors to a sane value).

-- 
Štěpán

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

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@smrk.net>
> Cc: 65267@debbugs.gnu.org, monnier@iro.umontreal.ca
> Date: Sun, 13 Aug 2023 12:03:41 +0200
> 
> On Sun, 13 Aug 2023 12:49:42 +0300
> Eli Zaretskii wrote:
> 
> > when the user says --debug-init, they need to be shown all the errors
> > raised during startup; hiding some of the errors was a misfeature in
> > previous versions of Emacs, now fixed.
> 
> That would seem OK to me.  The problem is that, as it is now, this
> breaks normal Emacs usage of anyone who starts with --debug-init and
> happens to modify `debug-ignored-errors' as part of their
> initialization.

You are not supposed to suppress errors during startup when you use
the --debug-init switch.  You are supposed to resolve the errors one
by one, until no errors are left.  (Resolving errors could include
catching them and ignoring them, e.g., with the likes of
ignore-errors.)  That's what --debug-init is for, so leaving some
errors suppressed in that case makes no sense.  Moreover, most users
don't even know that debug-ignored-errors exists and has a non-nil
value by default, so the effect is to hide some errors during startup
from those users -- and that is the anti-thesis of --debug-init.

> Note that it might not even be user-intentional/explicit modification,
> e.g., I noticed the problem because I load yasnippet from my init file,
> and yasnippet adds a custom regexp to debug-ignored-errors; so now I end
> up with bogus debug-ignored-errors value, which is further aggravated by
> the fact that I normally run with debug-on-errors set, so, for example,
> I now end up in the debugger whenever I press C-n at the end of buffer
> (until I manually restore debug-ignored-errors to a sane value).

The above works perfectly okay as long as --debug-init is not used,
right?  (If it doesn't, then this is not a problem with a recent
change that is supposed to affect only --debug-init.)

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

[Štěpán Němec]

On Sun, 13 Aug 2023 13:12:56 +0300
Eli Zaretskii wrote:

>> From: Štěpán Němec <stepnem@smrk.net>
>> Cc: 65267@debbugs.gnu.org, monnier@iro.umontreal.ca
>> Date: Sun, 13 Aug 2023 12:03:41 +0200
>> 
>> On Sun, 13 Aug 2023 12:49:42 +0300
>> Eli Zaretskii wrote:
>> 
>> > when the user says --debug-init, they need to be shown all the errors
>> > raised during startup; hiding some of the errors was a misfeature in
>> > previous versions of Emacs, now fixed.
>> 
>> That would seem OK to me.  The problem is that, as it is now, this
>> breaks normal Emacs usage of anyone who starts with --debug-init and
>> happens to modify `debug-ignored-errors' as part of their
>> initialization.
>
> You are not supposed to suppress errors during startup when you use
> the --debug-init switch.  You are supposed to resolve the errors one
> by one, until no errors are left.  (Resolving errors could include
> catching them and ignoring them, e.g., with the likes of
> ignore-errors.)  That's what --debug-init is for, so leaving some
> errors suppressed in that case makes no sense.  Moreover, most users
> don't even know that debug-ignored-errors exists and has a non-nil
> value by default, so the effect is to hide some errors during startup
> from those users -- and that is the anti-thesis of --debug-init.

I fail to see how any of that pertains to the issue at hand.  Just to be
a bit more certain we understand each other: no errors occur during
startup; I'm not talking about any kind of debugging scenario, or
suppressing errors during startup.  The bug I describe causes a
perfectly cleanly started Emacs to end up with bogus
debug-ignored-errors, possibly (even likely) without the user
intentionally modifying any defaults, other than passing --debug-init to
Emacs and loading (as part of initialization) a package that might add
to debug-ignored-errors, both of which seem perfectly fine things to do
to me (and had been working for years until the recent changes).

>> Note that it might not even be user-intentional/explicit modification,
>> e.g., I noticed the problem because I load yasnippet from my init file,
>> and yasnippet adds a custom regexp to debug-ignored-errors; so now I end
>> up with bogus debug-ignored-errors value, which is further aggravated by
>> the fact that I normally run with debug-on-errors set, so, for example,
>> I now end up in the debugger whenever I press C-n at the end of buffer
>> (until I manually restore debug-ignored-errors to a sane value).
>
> The above works perfectly okay as long as --debug-init is not used,
> right?  (If it doesn't, then this is not a problem with a recent
> change that is supposed to affect only --debug-init.)

Yes, I stated so in my report.

-- 
Štěpán

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

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@smrk.net>
> Cc: 65267@debbugs.gnu.org, monnier@iro.umontreal.ca
> Date: Sun, 13 Aug 2023 12:24:45 +0200
> 
> I fail to see how any of that pertains to the issue at hand.  Just to be
> a bit more certain we understand each other: no errors occur during
> startup; I'm not talking about any kind of debugging scenario, or
> suppressing errors during startup.  The bug I describe causes a
> perfectly cleanly started Emacs to end up with bogus
> debug-ignored-errors, possibly (even likely) without the user
> intentionally modifying any defaults, other than passing --debug-init to
> Emacs and loading (as part of initialization) a package that might add
> to debug-ignored-errors, both of which seem perfectly fine things to do
> to me (and had been working for years until the recent changes).

If debug-ignored-errors isn't returned to its original value after
Emacs starts, that's a bug that wasn't supposed to happen.

However, if I start Emacs as

  $ emacs --debug-init

and then evaluate debug-ignored-errors after it starts, I see the
original value.  So this part seems to work.  It is only if I add some
symbol to debug-ignored-errors in the init file that the problem
happens.  So I guess the convoluted logic in
startup--load-user-init-file is missing something, Stefan?

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> --8<--
> initdir=$(mktemp -d)
>
> echo "(add-to-list 'debug-ignored-errors 'my-error)" >"$initdir"/init.el
> emacs --debug-init --init-dir="$initdir" \
>       --eval '(message "%S" debug-ignored-errors)'
>
> rm -rf "$initdir"
> --8<--
>
> In the emacs thus started, the value of `debug-ignored-errors' is
> "(my-error startup--witness)" instead of `my-error' added to
> the default ignored error symbol list.

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, but it's not clear how to "revert" to "the value
it would have if we had not changed it" once we're finished processing
`init.el`.

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?


        Stefan

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

[Eli Zaretskii]

> Cc: 65267@debbugs.gnu.org
> Date: Sun, 13 Aug 2023 12:19:31 -0400
> From:  Stefan Monnier via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> 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, but it's not clear how to "revert" to "the value
> it would have if we had not changed it" once we're finished processing
> `init.el`.
> 
> 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?

We could document that modifying debug-ignored-errors only works
reliably if done from after-init-hook.  WDYT?

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

[Štěpán Němec]

On Sun, 13 Aug 2023 12:19:31 -0400
Stefan Monnier via wrote:

> 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, and even if they do occur during startup, why
should Emacs not respect debug-ignored-errors and ignore them?  (I also
couldn't find this exception (i.e., --debug-init causing
debug-ignored-errors to be ignored) documented anywhere, BTW.)

> but it's not clear how to "revert" to "the value
> it would have if we had not changed it" once we're finished processing
> `init.el`.
>
> 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...).

On Sun, 13 Aug 2023 19:32:46 +0300
Eli Zaretskii wrote:

> 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.

-- 
Štěpán

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

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@smrk.net>
> Date: Sun, 13 Aug 2023 19:08:26 +0200
> 
> On Sun, 13 Aug 2023 12:19:31 -0400
> Stefan Monnier via wrote:
> 
> > 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, and even if they do occur during startup, why
> should Emacs not respect debug-ignored-errors and ignore them?

If debug-ignored-errors were by default nil, then this would have made
sense.  But that's not the case: we set debug-ignored-errors to a
non-nil value by default, and that gets in the way of --debug-init.
See bug#64163.  How's that for user surprise?

> (I also couldn't find this exception (i.e., --debug-init causing
> debug-ignored-errors to be ignored) documented anywhere, BTW.)

The value set by the init file was not supposed to be ignored, only
our own self-imposed default was.  So there was nothing to document:
those are Emacs internals, and we tweak them to make --debug-init work
as expected, which is to catch every error.

> > 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.

Why on earth does yasnippet modify the value of a user variable?

> 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.

See above: it was the result of fixing a bug.

Another possibility, I guess, would be to set debug-ignored-errors to
its current default only after loading the user init file, and do that
in a way that _adds_ the ignored-by-default errors to the list it has
after loading init files.  Before loading the init files, the value
could would be nil.

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

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@smrk.net>
> Cc: monnier@iro.umontreal.ca, 65267@debbugs.gnu.org
> Date: Sun, 13 Aug 2023 20:35:25 +0200
> 
> > See bug#64163.  How's that for user surprise?
> 
> Well, I did read that report, but, rather than making me believe
> --debug-init should ignore debug-ignored-errors, it made me wonder if
> having `end-of-file' on debug-ignored-errors was a good idea to begin
> with.  It doesn't seem to fit the general user-error-like pattern of
> the other members.

Imagine that your init file has one of these errors and you want to
debug them with --debug-init.  Why wouldn't that be possible?

IOW, the --debug-init option is meant to allow the users to find out
_where_ in their init files the error which fails them happens, so it
makes very little sense to mask some of those errors when the
debugging mode is requested by the user.

> > Why on earth does yasnippet modify the value of a user variable?
> 
> I can't speak for yasnippet maintainers, but let's have a look at what
> GNU Emacs says, in the comment above debug-ignored-errors in
> bindings.el, line 879:
> 
> ;; Packages should add to this list appropriately when they are
> ;; loaded, rather than listing everything here.
> 
> Sounds somewhat suggestive.

It is easy to remove that comment.  User options shouldn't be touched
by packages.

> Granted, one might interpret "packages"
> above as internal-only, OTOH you call debug-ignored-errors a "user
> variable" (and indeed it is accessible from the Custom machinery).
> Maybe storing part of "Emacs internals" in a user variable isn't
> optimal, either?

By "Emacs internals" part I alluded to the fact that we temporarily
tweak the value for the benefit of making --debug-init as useful as
users expect.  It's similar to the fact that some user options are
evaluated more than once during startup, for some good reasons.

> In any case, even if we leave packages out of the
> equation, the recent change breaks anybody who peruses the user variable
> during init, so blessing the new behavior would cause some pain for some
> users (in addition to package maintainers).

There's no argument that the value of debug-ignored-errors should be
left after startup as users expect -- that it isn't so now is a bug
that needs to be fixed one way or another.  But the fact that using
the --debug-init option temporarily resets debug-ignored-errors to nil
while Emacs loads the init files is _not_ a bug, it's a feature
intended to meet user expectations from this option.

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

[ 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@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

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

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@smrk.net>
> Cc: Eli Zaretskii <eliz@gnu.org>, 65267@debbugs.gnu.org, Noam Postavsky
>  <npostavs@users.sourceforge.net>
> Date: Sun, 13 Aug 2023 22:34:58 +0200
> 
> So, yes, I agree that end-of-file (which indeed isn't unlikely to occur
> during loading) now ending up in the debugger is an improvement.
> 
> Checking git history, I also see that end-of-file has been in
> debug-ignored-errors since forever, but I still can't rid myself of
> doubts regarding its usefulness there.  Would you have an explanation
> for that, too?  Other than it not fitting with the others (IMHO), its
> absence there would likely save us all this (bug#64163 and the ensuing
> mess).  I find any of the other members of debug-ignored-errors being
> triggered during startup much less likely.  (And, OTOH, why would I want
> to ignore end-of-file during interactive use with d-o-e set?)

It is not ignored, it just doesn't enter the debugger.

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

[Štěpán Němec]

On Mon, 14 Aug 2023 05:26:15 +0300
Eli Zaretskii wrote:

>> From: Štěpán Němec <stepnem@smrk.net>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 65267@debbugs.gnu.org, Noam Postavsky
>>  <npostavs@users.sourceforge.net>
>> Date: Sun, 13 Aug 2023 22:34:58 +0200
>> 
>> So, yes, I agree that end-of-file (which indeed isn't unlikely to occur
>> during loading) now ending up in the debugger is an improvement.
>> 
>> Checking git history, I also see that end-of-file has been in
>> debug-ignored-errors since forever, but I still can't rid myself of
>> doubts regarding its usefulness there.  Would you have an explanation
>> for that, too?  Other than it not fitting with the others (IMHO), its
>> absence there would likely save us all this (bug#64163 and the ensuing
>> mess).  I find any of the other members of debug-ignored-errors being
>> triggered during startup much less likely.  (And, OTOH, why would I want
>> to ignore end-of-file during interactive use with d-o-e set?)
>
> It is not ignored, it just doesn't enter the debugger.

That's what I meant, sorry for not being clearer.

Unlike the other members of debug-ignored-errors, end-of-file doesn't
strike me as an error likely to cause annoyance rather than provide
useful backtrace data when running with debug-on-error set, so I don't
understand why it's there by default.  I'll remove it here and see how
that goes.

-- 
Štěpán

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

[Eli Zaretskii]

> 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)))

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

[Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors]

> 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.

No objection from me (it's not great, but I don't think there's a great
solution).


        Stefan

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

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: stepnem@smrk.net,  65267@debbugs.gnu.org,  npostavs@users.sourceforge.net
> Date: Thu, 17 Aug 2023 08:55:38 -0400
> 
> > 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.
> 
> No objection from me (it's not great, but I don't think there's a great
> solution).

Thanks.

Štěpán, would you mind testing the patch?  If it works for you, I will
install it.

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

[Štěpán Němec]

On Thu, 17 Aug 2023 16:28:31 +0300
Eli Zaretskii wrote:

>> From: Stefan Monnier <monnier@iro.umontreal.ca>
>> Cc: stepnem@smrk.net,  65267@debbugs.gnu.org,  npostavs@users.sourceforge.net
>> Date: Thu, 17 Aug 2023 08:55:38 -0400
>> 
>> > 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.
>> 
>> No objection from me (it's not great, but I don't think there's a great
>> solution).
>
> Thanks.
>
> Štěpán, would you mind testing the patch?  If it works for you, I will
> install it.

Your patch preserves additions (although it moves them to the end of the
list, but that shouldn't matter for debug-ignored-errors), but doesn't
preserve removals, e.g., if we change the reproducer from my original
report to

--8<--
initdir=$(mktemp -d)

#echo "(add-to-list 'debug-ignored-errors 'my-error)" >"$initdir"/init.el
echo "(setq debug-ignored-errors (delq 'end-of-file debug-ignored-errors))" >"$initdir"/init.el
emacs --debug-init --init-dir="$initdir" \
      --eval '(message "%S" debug-ignored-errors)'

rm -rf "$initdir"
--8<--

we end up with debug-ignored-errors containing `end-of-file' (together
with the rest).

Have you considered my humble suggestion of reverting to pre-bug#64163
state and simply removing end-of-file from the default value of
debug-ignored-errors?

-- 
Štěpán

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

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@smrk.net>
> Cc: 65267@debbugs.gnu.org, npostavs@users.sourceforge.net
> Date: Thu, 17 Aug 2023 16:16:19 +0200
> 
> On Thu, 17 Aug 2023 16:28:31 +0300
> Eli Zaretskii wrote:
> 
> >> From: Stefan Monnier <monnier@iro.umontreal.ca>
> >> Cc: stepnem@smrk.net,  65267@debbugs.gnu.org,  npostavs@users.sourceforge.net
> >> Date: Thu, 17 Aug 2023 08:55:38 -0400
> >> 
> >> > 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.
> >> 
> >> No objection from me (it's not great, but I don't think there's a great
> >> solution).
> >
> > Thanks.
> >
> > Štěpán, would you mind testing the patch?  If it works for you, I will
> > install it.
> 
> Your patch preserves additions (although it moves them to the end of the
> list, but that shouldn't matter for debug-ignored-errors), but doesn't
> preserve removals

If someone want to remove from the list, and use --debug-init on top
of that, they will need to replace the value instead.  If that's the
only downside of the patch I proposed, I think people will be able to
live with it.

> Have you considered my humble suggestion of reverting to pre-bug#64163
> state and simply removing end-of-file from the default value of
> debug-ignored-errors?

Yes.  This cannot fly, since we had end-of-file there for a long time
(I see it in Emacs 20).

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

[Eli Zaretskii]

> Cc: 65267@debbugs.gnu.org, monnier@iro.umontreal.ca,
>  npostavs@users.sourceforge.net
> Date: Thu, 17 Aug 2023 17:31:00 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> 
> > Have you considered my humble suggestion of reverting to pre-bug#64163
> > state and simply removing end-of-file from the default value of
> > debug-ignored-errors?
> 
> Yes.  This cannot fly, since we had end-of-file there for a long time
> (I see it in Emacs 20).

And, of course, end-of-file is just one of the errors in the list;
bug#64163 could have been equally reported with any of those other
ones, and the solution is the same.

bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken, bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken

[Štěpán Němec]

On Thu, 17 Aug 2023 17:31:00 +0300
Eli Zaretskii wrote:

>> From: Štěpán Němec <stepnem@smrk.net>
>> Cc: 65267@debbugs.gnu.org, npostavs@users.sourceforge.net
>> Date: Thu, 17 Aug 2023 16:16:19 +0200
>> 
>> On Thu, 17 Aug 2023 16:28:31 +0300
>> Eli Zaretskii wrote:
>> 
>> Your patch preserves additions (although it moves them to the end of the
>> list, but that shouldn't matter for debug-ignored-errors), but doesn't
>> preserve removals
>
> If someone want to remove from the list, and use --debug-init on top
> of that, they will need to replace the value instead.  If that's the
> only downside of the patch I proposed, I think people will be able to
> live with it.

As you said, debug-ignored-errors is a user variable.  So some people
are likely to change it, and some (most?) of those people will do that
from their init file.  I don't see how adding vs removing is any
different in that respect.

As for --debug-init, why would anyone (who knows about that option and
cares about their setup) routinely start Emacs *without* it?

>> Have you considered my humble suggestion of reverting to pre-bug#64163
>> state and simply removing end-of-file from the default value of
>> debug-ignored-errors?
>
> Yes.  This cannot fly, since we had end-of-file there for a long time
> (I see it in Emacs 20).

I only wish someone would put forth an actual argument for having
end-of-file on debug-ignored-errors.

I agree backward compatibility/preserving behavior is important, but I
hope you'll agree that some behavior changes are more
serious/visible/disruptive/whatever than others, and I'd argue that in
that sense, messing with user option modification during startup is a
worse change than removing end-of-file from debug-ignored-errors.

So if we're again back to blessing the breakage, I suggest it at least
be documented.

On Thu, 17 Aug 2023 17:36:09 +0300
Eli Zaretskii wrote:

>> Cc: 65267@debbugs.gnu.org, monnier@iro.umontreal.ca,
>>  npostavs@users.sourceforge.net
>> Date: Thu, 17 Aug 2023 17:31:00 +0300
>> From: Eli Zaretskii <eliz@gnu.org>
>> 
>> > Have you considered my humble suggestion of reverting to pre-bug#64163
>> > state and simply removing end-of-file from the default value of
>> > debug-ignored-errors?
>> 
>> Yes.  This cannot fly, since we had end-of-file there for a long time
>> (I see it in Emacs 20).
>
> And, of course, end-of-file is just one of the errors in the list;
> bug#64163 could have been equally reported with any of those other
> ones, and the solution is the same.

"Equally" I don't think.  If it took many (tens of?) years for anybody
to be bothered by the end-of-file case (bug#64163), which IME indeed
occurs somewhat regularly during startup (missing closing paren), I find
the same happening with any of the other members of debug-ignored-errors
exceedingly unlikely.

I agree with Stefan that no good solution has so far emerged.  The
advantage of my suggestion would be that it only changes
debug-ignored-errors in a way that makes sense anyway (in absence of any
arguments to the contrary), preventing bug#64163 as a byproduct, rather
than adding to convoluted code nobody involved seems to really
understand in a way that nobody involved seems to really understand or
expect.

-- 
Štěpán

bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken, bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@smrk.net>
> Cc: 65267@debbugs.gnu.org,  monnier@iro.umontreal.ca,
>   npostavs@users.sourceforge.net
> Date: Thu, 17 Aug 2023 17:52:59 +0200
> 
> As you said, debug-ignored-errors is a user variable.  So some people
> are likely to change it, and some (most?) of those people will do that
> from their init file.  I don't see how adding vs removing is any
> different in that respect.

I agree, I'm just saying that removing from the list, and using
 --debug-init at the same time is beyond obscure.

> As for --debug-init, why would anyone (who knows about that option and
> cares about their setup) routinely start Emacs *without* it?

I would actually ask the opposite: why would someone run with that
option except when they need to debug their init files?  It's a
debugging option.  I'm quite sure that if you poll Emacs users, you
will find that the vast majority doesn't routinely use that option.
Exactly like most of the users don't routinely run Emacs under GDB.

> >> Have you considered my humble suggestion of reverting to pre-bug#64163
> >> state and simply removing end-of-file from the default value of
> >> debug-ignored-errors?
> >
> > Yes.  This cannot fly, since we had end-of-file there for a long time
> > (I see it in Emacs 20).
> 
> I only wish someone would put forth an actual argument for having
> end-of-file on debug-ignored-errors.

It no longer matters, since that ship has sailed in Sep 1996, if not
earlier.

> I agree backward compatibility/preserving behavior is important, but I
> hope you'll agree that some behavior changes are more
> serious/visible/disruptive/whatever than others, and I'd argue that in
> that sense, messing with user option modification during startup is a
> worse change than removing end-of-file from debug-ignored-errors.

If we "mess" with the options and restore them back to their
user-defined value at the end of startup, the "mess" is not that awful
a felony.  During startup, Emacs "messes" with some options anyway,
e.g., those that need to be re-evaluated more than once, to support
the user changing the environment via init file settings.  So it isn't
like there's no precedent for "messing" with user options.

And let me remind you that this bug report was triggered by "messing"
with user options by a certain package.

> So if we're again back to blessing the breakage, I suggest it at least
> be documented.

I don't think I have a clear idea of what aspects of this you think we
need to document.  Please elaborate.

bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken, bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken

[Štěpán Němec]

On Thu, 17 Aug 2023 19:05:55 +0300
Eli Zaretskii wrote:

>> From: Štěpán Němec <stepnem@smrk.net>
>> Cc: 65267@debbugs.gnu.org,  monnier@iro.umontreal.ca,
>>   npostavs@users.sourceforge.net
>> Date: Thu, 17 Aug 2023 17:52:59 +0200
>> 
>> As you said, debug-ignored-errors is a user variable.  So some people
>> are likely to change it, and some (most?) of those people will do that
>> from their init file.  I don't see how adding vs removing is any
>> different in that respect.
>
> I agree, I'm just saying that removing from the list, and using
>  --debug-init at the same time is beyond obscure.

Why?

>> As for --debug-init, why would anyone (who knows about that option and
>> cares about their setup) routinely start Emacs *without* it?
>
> I would actually ask the opposite: why would someone run with that
> option except when they need to debug their init files?  It's a
> debugging option.

Because in the no-errors case it costs the user virtually nothing, and
in case of errors you don't have to restart with --debug-init: you have
the backtrace right there.

> I'm quite sure that if you poll Emacs users, you will find that the
> vast majority doesn't routinely use that option.

I don't share your confidence, one way or the other; you might well be
right (that's why I added the parenthetical).

> Exactly like most of the users don't routinely run Emacs under GDB.

Running under GDB is significantly more complex (esp. for a casual user)
than adding a CLI option, so I don't think that is a good comparison.

>> >> Have you considered my humble suggestion of reverting to pre-bug#64163
>> >> state and simply removing end-of-file from the default value of
>> >> debug-ignored-errors?
>> >
>> > Yes.  This cannot fly, since we had end-of-file there for a long time
>> > (I see it in Emacs 20).
>> 
>> I only wish someone would put forth an actual argument for having
>> end-of-file on debug-ignored-errors.
>
> It no longer matters, since that ship has sailed in Sep 1996, if not
> earlier.

Even GNU Emacs is amenable to such reassessments.  Options and/or their
defaults change every release, I don't see how debug-ignored-errors is
any different (if anything, this change would seem relatively minor).

>> I agree backward compatibility/preserving behavior is important, but I
>> hope you'll agree that some behavior changes are more
>> serious/visible/disruptive/whatever than others, and I'd argue that in
>> that sense, messing with user option modification during startup is a
>> worse change than removing end-of-file from debug-ignored-errors.
>
> If we "mess" with the options and restore them back to their
> user-defined value at the end of startup, the "mess" is not that awful
> a felony.  During startup, Emacs "messes" with some options anyway,
> e.g., those that need to be re-evaluated more than once, to support
> the user changing the environment via init file settings.  So it isn't
> like there's no precedent for "messing" with user options.
>
> And let me remind you that this bug report was triggered by "messing"
> with user options by a certain package.
>
>> So if we're again back to blessing the breakage, I suggest it at least
>> be documented.
>
> I don't think I have a clear idea of what aspects of this you think we
> need to document.  Please elaborate.

I thought it was obvious, but I see I should have been more precise
again, I apologize and reformulate: the "mess" here isn't with the
option per se, but with its customization (even though the end result
is, of course, a wrong (not user-intended) value of the option per se).

Your patch doesn't improve that situation: if a user changes
debug-ignored-errors during initialization, they might end up
(silently!) with an unexpected value.  Don't you agree that makes
debug-ignored-errors special enough to need documenting?

-- 
Štěpán

bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken, bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken

[Gregory Heytings]

>> Yes.  This cannot fly, since we had end-of-file there for a long time 
>> (I see it in Emacs 20).
>
> I only wish someone would put forth an actual argument for having 
> end-of-file on debug-ignored-errors.
>

See NEWS.19:

** The variable 'debug-ignored-errors' specifies certain kinds of errors 
that should not enter the debugger.  Its value is a list of error 
condition symbols and/or regular expressions.  If the error has any of the 
condition symbols listed, or if any of the regular expressions matches the 
error message, then that error does not enter the debugger, regardless of 
the value of debug-on-error.

This variable is initialized to match certain common but uninteresting 
errors that happen often during editing.

To see what this means in practice, try:

emacs -Q
M-: (setq debug-ignored-errors nil) RET
M-x toggle-debug-on-error RET
"
M-x eval-buffer RET

bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken, bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken

[Štěpán Němec]

On Thu, 17 Aug 2023 17:15:03 +0000
Gregory Heytings wrote:

>>> Yes.  This cannot fly, since we had end-of-file there for a long time 
>>> (I see it in Emacs 20).
>>
>> I only wish someone would put forth an actual argument for having 
>> end-of-file on debug-ignored-errors.
>>
>
> See NEWS.19:
>
> ** The variable 'debug-ignored-errors' specifies certain kinds of errors 
> that should not enter the debugger.  Its value is a list of error 
> condition symbols and/or regular expressions.  If the error has any of the 
> condition symbols listed, or if any of the regular expressions matches the 
> error message, then that error does not enter the debugger, regardless of 
> the value of debug-on-error.
>
> This variable is initialized to match certain common but uninteresting 
> errors that happen often during editing.
>
> To see what this means in practice, try:
>
> emacs -Q
> M-: (setq debug-ignored-errors nil) RET
> M-x toggle-debug-on-error RET
> "
> M-x eval-buffer RET

Thank you, but I believe we all knew that, already.  My point has been
that end-of-file doesn't really belong to the "common but uninteresting
errors that happen often during editing", and your example doesn't
change that, no.

I guess I can imagine some kind of
constantly-evaling-buffer-no-matter-what automation, triggered by
examples like yours, leading to annoyance, but I'm not aware of such a
thing (and would consider such automation broken if it existed; surely
it would at least have to be handling end-of-file itself anyway).

-- 
Štěpán

bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken, bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@smrk.net>
> Cc: 65267@debbugs.gnu.org, monnier@iro.umontreal.ca,
>  npostavs@users.sourceforge.net
> Date: Thu, 17 Aug 2023 18:29:58 +0200
> 
> > I agree, I'm just saying that removing from the list, and using
> >  --debug-init at the same time is beyond obscure.
> 
> Why?

A hunch, based on a lot of years of talking to users who had problems
in their init files.

> >> As for --debug-init, why would anyone (who knows about that option and
> >> cares about their setup) routinely start Emacs *without* it?
> >
> > I would actually ask the opposite: why would someone run with that
> > option except when they need to debug their init files?  It's a
> > debugging option.
> 
> Because in the no-errors case it costs the user virtually nothing, and
> in case of errors you don't have to restart with --debug-init: you have
> the backtrace right there.

That's not how people regard use of debugging tools, usually.

> > Exactly like most of the users don't routinely run Emacs under GDB.
> 
> Running under GDB is significantly more complex (esp. for a casual user)
> than adding a CLI option

No, it doesn't.  Starting a program from GDB is very similar to
starting a program from the shell prompt.  GDB was intentionally
written to work like a shell in this regard, complete with searching
PATH, supporting redirection, etc.

> >> I only wish someone would put forth an actual argument for having
> >> end-of-file on debug-ignored-errors.
> >
> > It no longer matters, since that ship has sailed in Sep 1996, if not
> > earlier.
> 
> Even GNU Emacs is amenable to such reassessments.  Options and/or their
> defaults change every release, I don't see how debug-ignored-errors is
> any different (if anything, this change would seem relatively minor).

We are extremely conservative with changing the defaults of user
options, and usually require a very good reason for doing that.  I see
no such good reason here, as the behavior modified after bug#64163 is
better than the old one.

> > I don't think I have a clear idea of what aspects of this you think we
> > need to document.  Please elaborate.
> 
> I thought it was obvious, but I see I should have been more precise
> again, I apologize and reformulate: the "mess" here isn't with the
> option per se, but with its customization (even though the end result
> is, of course, a wrong (not user-intended) value of the option per se).
> 
> Your patch doesn't improve that situation: if a user changes
> debug-ignored-errors during initialization, they might end up
> (silently!) with an unexpected value.  Don't you agree that makes
> debug-ignored-errors special enough to need documenting?

I'm still not sure I understand: do you want us to document that if
debug-ignored-errors are modified in the init files, they sometimes
might end up with an unexpected value?  If so, I don't think this kind
of documentation will be useful.  In the (IMO improbable) case that
someone will want to remove errors from the default value, as opposed
to simply set it to the value they want, I prefer to receive a bug
report and explain that removing is not supported with --debug-init,
rather than have something like that in the documentation, where it
will almost certainly be very hard to discover.

bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken, bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken

[Gregory Heytings]

>
> Thank you, but I believe we all knew that, already.
>

I apologize for trying to help.

>
> My point has been that end-of-file doesn't really belong to the "common 
> but uninteresting errors that happen often during editing", and your 
> example doesn't change that, no.
>

I'd say that the fact that end-of-file has been in the default value of 
debug-ignored-errors for a quarter of a century without anyone objecting 
indicates that it's a reasonable default.  And you can easily remove it 
from there if you want:

(delq 'end-of-file debug-ignored-errors)

bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken, bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken

[Štěpán Němec]

On Thu, 17 Aug 2023 20:58:00 +0300
Eli Zaretskii wrote:

>> Running under GDB is significantly more complex (esp. for a casual user)
>> than adding a CLI option
>
> No, it doesn't.  Starting a program from GDB is very similar to
> starting a program from the shell prompt.  GDB was intentionally
> written to work like a shell in this regard, complete with searching
> PATH, supporting redirection, etc.

Yes, after one has installed GDB, learnt how to use it and set it up to
be useful with Emacs, the mere act of *starting* it is relatively easy,
indeed...

> I'm still not sure I understand: do you want us to document that if
> debug-ignored-errors are modified in the init files, they sometimes
> might end up with an unexpected value?

Yes.  (I think you mentioned something about saying that it's only safe
to do so from after-init-hook or some such in a previous message.)

> If so, I don't think this kind of documentation will be useful.

Certainly more useful than silently breaking user's setup?  (Which I
still don't think should be done at all, silent or not, but doing so
tacitly seems more on the user-hostile side.)

> In the (IMO improbable) case that someone will want to remove errors
> from the default value, as opposed to simply set it to the value they
> want, I prefer to receive a bug report and explain that removing is
> not supported with --debug-init, rather than have something like that
> in the documentation, where it will almost certainly be very hard to
> discover.

IMHO it should be (at least) in the doc string of debug-ignored-errors.

-- 
Štěpán

bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken, bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken

[Štěpán Němec]

On Thu, 17 Aug 2023 18:07:55 +0000
Gregory Heytings wrote:

>>
>> Thank you, but I believe we all knew that, already.
>>
>
> I apologize for trying to help.

Well, I don't apologize for (*sincerely*) thanking you.

> I'd say that the fact that end-of-file has been in the default value of 
> debug-ignored-errors for a quarter of a century without anyone objecting 
> indicates that it's a reasonable default.  And you can easily remove it 
> from there if you want:
>
> (delq 'end-of-file debug-ignored-errors)

Maybe you know something about `delq' I do not, but I always use
something like

  (setq debug-ignored-errors (delq 'end-of-file debug-ignored-errors))

instead.  (See the documentation of `delq'.)

-- 
Štěpán

bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken, bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken

[Gregory Heytings]

>> (delq 'end-of-file debug-ignored-errors)
>
> Maybe you know something about `delq' I do not, but I always use 
> something like
>
> (setq debug-ignored-errors (delq 'end-of-file debug-ignored-errors))
>
> instead.  (See the documentation of `delq'.)
>

Indeed it's safer to write it that way, but the setq is in fact necessary 
only when the element you want to remove is the first element of the list, 
which isn't the case here.

bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken, bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken

[Štěpán Němec]

On Thu, 17 Aug 2023 18:31:34 +0000
Gregory Heytings wrote:

>>> (delq 'end-of-file debug-ignored-errors)
>>
>> Maybe you know something about `delq' I do not, but I always use 
>> something like
>>
>> (setq debug-ignored-errors (delq 'end-of-file debug-ignored-errors))
>>
>> instead.  (See the documentation of `delq'.)
>>
>
> Indeed it's safer to write it that way, but the setq is in fact
> necessary only when the element you want to remove is the first
> element of the list, which isn't the case here.

I didn't know that, thank you.  (I can't imagine a situation where I
would consider relying on that implementation detail a good idea,
though.)

-- 
Štěpán

bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken, bug#65267: 30.0.50; modifying debug-ignored-errors during startup with --debug-init is broken

[Eli Zaretskii]

> From: Štěpán Němec <stepnem@smrk.net>
> Cc: 65267@debbugs.gnu.org, monnier@iro.umontreal.ca,
>  npostavs@users.sourceforge.net
> Date: Thu, 17 Aug 2023 20:15:02 +0200
> 
> On Thu, 17 Aug 2023 20:58:00 +0300
> Eli Zaretskii wrote:
> 
> >> Running under GDB is significantly more complex (esp. for a casual user)
> >> than adding a CLI option
> >
> > No, it doesn't.  Starting a program from GDB is very similar to
> > starting a program from the shell prompt.  GDB was intentionally
> > written to work like a shell in this regard, complete with searching
> > PATH, supporting redirection, etc.
> 
> Yes, after one has installed GDB, learnt how to use it and set it up to
> be useful with Emacs, the mere act of *starting* it is relatively easy,
> indeed...

I'm told that nowadays installing GDB boils down to running a single
command of the package manager.

> > I'm still not sure I understand: do you want us to document that if
> > debug-ignored-errors are modified in the init files, they sometimes
> > might end up with an unexpected value?
> 
> Yes.  (I think you mentioned something about saying that it's only safe
> to do so from after-init-hook or some such in a previous message.)
> 
> > If so, I don't think this kind of documentation will be useful.
> 
> Certainly more useful than silently breaking user's setup?  (Which I
> still don't think should be done at all, silent or not, but doing so
> tacitly seems more on the user-hostile side.)
> 
> > In the (IMO improbable) case that someone will want to remove errors
> > from the default value, as opposed to simply set it to the value they
> > want, I prefer to receive a bug report and explain that removing is
> > not supported with --debug-init, rather than have something like that
> > in the documentation, where it will almost certainly be very hard to
> > discover.
> 
> IMHO it should be (at least) in the doc string of debug-ignored-errors.

I added something to the doc string.  Let's see if this will be
discovered by someone.

And with that, I'm closing this bug.