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: Štěpán Němec <stepnem <at> smrk.net>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 65267 <at> debbugs.gnu.org, monnier <at> iro.umontreal.ca, npostavs <at> users.sourceforge.net
Subject: 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
Date: Thu, 17 Aug 2023 18:29:58 +0200

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

>> From: Štěpán Němec <stepnem <at> smrk.net>
>> Cc: 65267 <at> debbugs.gnu.org,  monnier <at> iro.umontreal.ca,
>>   npostavs <at> 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

Previous Next

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