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.