Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Sat, 14 Oct 2023 22:25:37 +0000 (UTC) >> Cc: Spencer Baugh , 66326@debbugs.gnu.org >> >> Eli Zaretskii writes: >> >> >> From: Spencer Baugh >> >> Cc: sbaugh@catern.com, 66326@debbugs.gnu.org >> >> Date: Wed, 04 Oct 2023 08:20:49 -0400 >> >> >> >> Eli Zaretskii writes: >> >> > And in this case, duplication is a lesser evil than reordering of >> >> > logic, since the chances of unintended consequences would be lower in >> >> > the former case. >> >> >> >> OK, how about this version then? >> > >> > This is much better, thanks. But it still fails to execute this part >> > right away: >> > >> > (if (not (or after-init-time noninteractive (daemonp))) >> > ;; Ensure warnings that happen early in the startup sequence >> > ;; are visible when startup completes (bug#20792). >> > (delay-warning type message level buffer-name) >> > >> > We must preserve this functionality, unaffected by these changes. The >> > patch you propose doesn't seem to guarantee that, at least not >> > clearly enough for my palate. >> >> Ah, actually that's deliberate. > > If it's deliberate, it will have to come with an additional option to > enable it. I don't want users to have their startup aborted just > because they want some warning later on converted to an error. > Startup is a delicate process where signaling errors is not always a > good idea, and we delay warnings there for a good reason. Changing > this unconditionally is not acceptable. What is the good reason that we delay warnings? AFAIK the reason is solely that the warnings would not be visible. Which is indeed a good reason, but does not apply if the warnings are turned into errors. But OK, attached is a new patch which adds an option to immediately raise the warnings converted into errors during startup, instead of delaying them. So the default is to delay the error until after startup. Does this work? >> (And that's one of the motivations of this change: to make it easier to >> debug a warning that happens during startup, by turning it into an error >> that can be debug-init'd) > > There's no difficulty in debugging a warning whatsoever, IME. It is a > serious exaggeration to claim that there's a significant problem here > that needs a solution. I'm curious: if you have some piece of code which warns during startup, how would you find out why that code is running? e.g., how would you figure out what function is calling some other code which internally warns? This seems pretty difficult to me. > Nevertheless, I'm okay with people opting in to shooting themselves in > the foot, I just don't agree to doing that without an explicit user's > consent.