bug#66326: 29.1.50; There should be a way to promote warnings to errors

[Eli Zaretskii]

> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: sbaugh@catern.com,  66326@debbugs.gnu.org
> Date: Thu, 19 Oct 2023 12:15:52 -0400
> 
> > What worries me more is that there's a way to signal an error that
> > could crash Emacs during these early stages of startup.
> 
> I ask this because I genuinely want to understand: Is it a problem for a
> error to be signaled during these early stages of startup?  It will
> prevent Emacs from starting, of course, but is that a problem if this
> just causes Emacs to exit and print an error?

Signaling errors activates a complex mechanism, which unwinds the Lisp
machine stack to top-level and displays various kinds of information.
Being able to do this requires some basic setup of the Lisp machine
and redisplay, and that doesn't happen miraculously, it is the result
of running some bootstrap-like code during startup.  If you signal an
error before this stuff is ready, or try to display something before
Emacs is ready for that, you can cause a segfault or an abort.

That is all I can afford saying; if you want more details, you will
have to study the code, where you will see, for example, that
sometimes some of the display routines return without doing anything
if they detect that the necessary infrastructure is not available.
I'm trying to prevent you from having to study the code, by asking you
not to enable any such dangerous behavior by default, but if you
insist on understanding every single detail, you will have to dive
into the code, because I cannot afford posting detailed lectures about
that -- it will take too much of my scarce free time.

> My apologies, I am not intending to dismiss what you're saying, I really
> do want to understand the issue.  I'm just keeping an open mind: I don't
> yet know whether the issue you're raising can actually cause a problem.
> Or, if there is a problem, if maybe there's a way to solve the problem
> other than this warning-signal-errors-during-startup variable.  That's
> why I'm trying to understand.  I'd appreciate it if you'd keep an open
> mind about it too.

I _am_ keeping an open mind.  If I didn't, I would just reject your
proposal from the get-go, because I have reasons to believe that its
risks are way greater than its potential usefulness to Emacs users at
large.

More generally, I'm worried by the tendency of people to submit
patches for Emacs as soon as they find something they think is missing
in Emacs that they need for some one-time job.  Emacs is not supposed
to be a huge heap of random features that someone at some time found
useful for some random job.  Emacs is Free Software: you can easily
implement this stuff in your local copy and use it as much as you
want; no need to add that to the Emacs core, unless there's a real
need for it expressed by enough people, and no better solutions in
hand.  I do this for my local jobs all the time.

So I would be much happier if, instead of dumping a patch on us,
people would first describe the issue and the idea on emacs-devel and
ask if anyone else had those problems and likes the solution.  Posting
patches is a kind of pressure on the maintainers: it is harder for the
maintainers to reject a contribution than to explain why a problem is
not important enough to be solved in core or an idea for its solution
is not the best one.