all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
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.





  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

* 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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.