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.