From: Eli Zaretskii <eliz@gnu.org>
To: sbaugh@catern.com
Cc: 68799@debbugs.gnu.org, sbaugh@janestreet.com
Subject: bug#68799: 30.0.50; emacs --fg-daemon fails silently if server-start fails
Date: Sat, 10 Feb 2024 22:05:58 +0200 [thread overview]
Message-ID: <868r3st789.fsf@gnu.org> (raw)
In-Reply-To: <875xywp08p.fsf@catern.com> (sbaugh@catern.com)
> From: sbaugh@catern.com
> Date: Sat, 10 Feb 2024 19:50:20 +0000 (UTC)
> Cc: Spencer Baugh <sbaugh@janestreet.com>, 68799@debbugs.gnu.org
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> >> > Thanks, this needs a comment explaining why we need condition-case and
> >> > where does error-message-string come from.
> >>
> >> Actually, on second thought, we could fail anywhere in startup.el, not
> >> just in server-start. So should we actually have a wrapper around all
> >> of normal-top-level which detects an error at startup in a daemon?
> >
> > I'd prefer to handle each specific problem specially, to make sure the
> > error message is self-explanatory. Also, if the error happens after
> > the server has been started, there's no reason to forcibly exit.
> >
> > So I think we should for now solve this particular issue, and not try
> > generalizing too much.
>
> To be clear, right now any error anywhere in command-line causes "emacs
> --fg-daemon" and "emacs --bg-daemon" to hang indefinitely, without
> printing an error, with no way to ever interact with the Emacs process.
That's not what you said before: you said "anywhere in startup.el",
which is much more general. Now you are saying something different.
What exactly is meant by "anywhere in command-line"? the function
command-line in startup.el? or something else?
> This error can come from any code, so if we have *any* bugs anywhere in
> code called from command-line, it will cause Emacs to enter this state.
Why would we assume that *any code* there will signal an error?
That's like saying that Emacs is a useless program that always signals
errors in random places. That's a non-starter here.
> We can add good error messages for individual classes of error, but we
> should also have a catch-all check to make sure that Emacs doesn't enter
> this broken state if we (or the user) write code which contains a bug.
There's no reason to have a catch-all check where no error is
expected. Do you always wrap all of your code in condition-case and
the likes? If not, why not?
> I have concrete reasons to want this: I think there's a bug in
> command-line in trunk which some of my users using emacs --daemon have
> run into. But I have zero information about what caused the bug,
> because Emacs just hangs without printing any error message in this
> case.
Then please debug that, and let's talk when you do have concrete data.
> To allow users to report bugs that are at all useful, we should at least
> print the error that occurred, even if we don't kill Emacs.
Users aren't supposed to debug Emacs, it's the job of developers. And
developers know how to run Emacs under a debugger and do any number of
other debugging tricks. Injecting debugging code into Emacs just
because some of your users did something wrong is not a good idea. Or
maybe it is -- but we won't know until we understand what exactly goes
wrong in those cases.
next prev parent reply other threads:[~2024-02-10 20:05 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-29 16:54 bug#68799: 30.0.50; emacs --fg-daemon fails silently if server-start fails Spencer Baugh
2024-01-29 17:11 ` Eli Zaretskii
2024-01-29 17:18 ` Eli Zaretskii
2024-01-29 17:32 ` Spencer Baugh
2024-01-29 17:44 ` Eli Zaretskii
2024-01-29 18:13 ` Spencer Baugh
2024-01-29 19:12 ` Eli Zaretskii
2024-01-29 20:28 ` Spencer Baugh
2024-01-30 12:08 ` Eli Zaretskii
2024-02-10 19:50 ` sbaugh
2024-02-10 20:05 ` Eli Zaretskii [this message]
2024-02-10 23:23 ` sbaugh
2024-02-11 7:24 ` Eli Zaretskii
2024-02-12 22:10 ` Spencer Baugh
2024-02-13 12:35 ` Eli Zaretskii
2024-02-13 17:37 ` Spencer Baugh
2024-02-13 17:49 ` Eli Zaretskii
2024-02-13 18:04 ` Spencer Baugh
2024-02-13 19:46 ` Eli Zaretskii
2024-02-13 20:02 ` Spencer Baugh
2024-02-13 20:04 ` Eli Zaretskii
2024-02-13 20:20 ` Spencer Baugh
2024-02-14 14:23 ` Eli Zaretskii
2024-02-14 16:11 ` Spencer Baugh
2024-02-24 9:20 ` Eli Zaretskii
2024-02-13 13:02 ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-02-13 21:30 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <875xys127y.fsf@>
2024-02-14 14:35 ` Eli Zaretskii
2024-02-14 15:10 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
[not found] ` <87plwzytcg.fsf@>
2024-02-14 15:31 ` Eli Zaretskii
2024-02-14 17:40 ` Björn Bidar via Bug reports for GNU Emacs, the Swiss army knife of text editors
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=868r3st789.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=68799@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).