unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Spencer Baugh <sbaugh@janestreet.com>
Cc: sbaugh@catern.com, 66326@debbugs.gnu.org
Subject: bug#66326: 29.1.50; There should be a way to promote warnings to errors
Date: Fri, 20 Oct 2023 10:20:11 +0300	[thread overview]
Message-ID: <83v8b1sqtw.fsf@gnu.org> (raw)
In-Reply-To: <ier34y64mh3.fsf@janestreet.com> (message from Spencer Baugh on Thu, 19 Oct 2023 12:15:52 -0400)

> 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.





  reply	other threads:[~2023-10-20  7:20 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-10-03 16:38 bug#66326: 29.1.50; There should be a way to promote warnings to errors Spencer Baugh
2023-10-03 18:39 ` Spencer Baugh
2023-10-03 18:57   ` Eli Zaretskii
2023-10-03 19:16     ` sbaugh
2023-10-04  5:59       ` Eli Zaretskii
2023-10-04 12:20         ` Spencer Baugh
2023-10-14  7:27           ` Eli Zaretskii
2023-10-14 22:25             ` sbaugh
2023-10-15  5:45               ` Eli Zaretskii
2023-10-16 19:26                 ` Spencer Baugh
2023-10-19 12:13                   ` Eli Zaretskii
2023-10-19 14:50                     ` Spencer Baugh
2023-10-19 15:07                       ` Eli Zaretskii
2023-10-19 15:18                         ` Spencer Baugh
2023-10-19 15:42                           ` Eli Zaretskii
2023-10-19 16:15                             ` Spencer Baugh
2023-10-20  7:20                               ` Eli Zaretskii [this message]
2023-10-21  9:12                                 ` Stefan Kangas
2023-10-21 13:43                                   ` sbaugh
2023-11-10 21:40                                     ` Spencer Baugh
2023-11-11  7:02                                       ` Eli Zaretskii
2023-11-11 14:37                                         ` Spencer Baugh
2023-11-11 14:51                                           ` Eli Zaretskii

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83v8b1sqtw.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=66326@debbugs.gnu.org \
    --cc=sbaugh@catern.com \
    --cc=sbaugh@janestreet.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).