GNU bug report logs - #76772
29.4; Emacsclient doesn't display warnings emitted during daemon startup

Previous Next

To reply to this bug, email your comments to 76772 AT debbugs.gnu.org.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Artiom Balan <artiombalan331 <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 29.4;
 Emacsclient doesn't display warnings emitted during daemon startup
Date: Wed, 5 Mar 2025 23:47:26 +0200

[Message part 1 (text/plain, inline)]

Steps to reproduce:
1. Run emacs: emacs -Q --eval "(display-warning 'type \"message\"))"
2. Notice the warning is displayed
3. Start emacs server: emacs -Q --fg-daemon --eval "(display-warning 'type
\"message\"))"
4. Open a client: emacsclient -c
5. Notice the warning is not displayed

I expected that the warnings buffer would be displayed in the exact
same way in the emacsclient as in the first scenario.


In GNU Emacs 29.4 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.48,
cairo version 1.18.2)

[Message part 2 (text/html, inline)]

Message #8 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Artiom Balan <artiombalan331 <at> gmail.com>
Cc: 76772 <at> debbugs.gnu.org
Subject: Re: bug#76772: 29.4;
 Emacsclient doesn't display warnings emitted during daemon startup
Date: Thu, 06 Mar 2025 10:23:55 +0200

tags 76772 notabug
thanks

> From: Artiom Balan <artiombalan331 <at> gmail.com>
> Date: Wed, 5 Mar 2025 23:47:26 +0200
> 
> Steps to reproduce:
> 1. Run emacs: emacs -Q --eval "(display-warning 'type \"message\"))"
> 2. Notice the warning is displayed
> 3. Start emacs server: emacs -Q --fg-daemon --eval "(display-warning 'type \"message\"))"
> 4. Open a client: emacsclient -c
> 5. Notice the warning is not displayed
> 
> I expected that the warnings buffer would be displayed in the exact
> same way in the emacsclient as in the first scenario.

Thanks.

The *Warnings* buffer is there, it's just that the client frame
doesn't show it.  Why should it? how should it know you want that
particular buffer displayed without any indication from you?

Try this, and you will see the warning in the client frame:

  emacsclient -c --eval "(display-buffer \"*Warnings*\")"

I don't see a bug here.

Message #13 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Artiom Balan <artiombalan331 <at> gmail.com>
To: 76772 <at> debbugs.gnu.org
Date: Thu, 6 Mar 2025 10:56:29 +0200

[Message part 1 (text/plain, inline)]

> The *Warnings* buffer is there, it's just that the client frame doesn't
show it.
Sorry, yes that's what I meant.

> Why should it?
For the same reason that the warnings buffer is displayed in a regular
emacs instance if there have been any warnings emitted during startup.

> how should it know you want that particular buffer displayed without any
indication from you?
I think the warnings buffer should be displayed in the first emacsclient
created after startup (if there are any warnings). Then the following
clients shouldn't display the warnings buffer, because the user has already
seen it.

[Message part 2 (text/html, inline)]

Message #16 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Artiom Balan <artiombalan331 <at> gmail.com>
Cc: 76772 <at> debbugs.gnu.org
Subject: Re: bug#76772: 29.4; Emacsclient doesn't display warnings emitted
 during daemon startup
Date: Thu, 6 Mar 2025 01:25:37 -0800

Eli Zaretskii <eliz <at> gnu.org> writes:

> tags 76772 notabug
> thanks
>
>> From: Artiom Balan <artiombalan331 <at> gmail.com>
>> Date: Wed, 5 Mar 2025 23:47:26 +0200
>>
>> Steps to reproduce:
>> 1. Run emacs: emacs -Q --eval "(display-warning 'type \"message\"))"
>> 2. Notice the warning is displayed
>> 3. Start emacs server: emacs -Q --fg-daemon --eval "(display-warning 'type \"message\"))"
>> 4. Open a client: emacsclient -c
>> 5. Notice the warning is not displayed
>>
>> I expected that the warnings buffer would be displayed in the exact
>> same way in the emacsclient as in the first scenario.
>
> Thanks.
>
> The *Warnings* buffer is there, it's just that the client frame
> doesn't show it.  Why should it? how should it know you want that
> particular buffer displayed without any indication from you?

We show it unconditionally in regular Emacs sessions, so it is at the
very least surprising that it is not displayed in the scenario described
above.

I would have expected Emacs to make an effort to display it to me.

> Try this, and you will see the warning in the client frame:
>
>   emacsclient -c --eval "(display-buffer \"*Warnings*\")"
>
> I don't see a bug here.

Message #19 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Artiom Balan <artiombalan331 <at> gmail.com>
Cc: 76772 <at> debbugs.gnu.org
Subject: Re: bug#76772:
Date: Thu, 06 Mar 2025 16:13:31 +0200

> From: Artiom Balan <artiombalan331 <at> gmail.com>
> Date: Thu, 6 Mar 2025 10:56:29 +0200
> 
> > The *Warnings* buffer is there, it's just that the client frame doesn't show it.
> Sorry, yes that's what I meant.
> 
> > Why should it?
> For the same reason that the warnings buffer is displayed in a regular emacs instance if there have been any
> warnings emitted during startup.

Emacs displays it because that's the first command it executes after
starting.  By contrast, in the daemon case, there's no relation
between the --eval argument when starting the daemon and the client
frame displayed because emacsclient connected, these events could be
many minutes apart.

> > how should it know you want that particular buffer displayed without any indication from you?
> I think the warnings buffer should be displayed in the first emacsclient created after startup (if there are any
> warnings). Then the following clients shouldn't display the warnings buffer, because the user has already
> seen it.

I don't think your expectations are correct, but let's hear what
others think.

Message #22 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 76772 <at> debbugs.gnu.org, artiombalan331 <at> gmail.com
Subject: Re: bug#76772: 29.4; Emacsclient doesn't display warnings emitted
 during daemon startup
Date: Thu, 06 Mar 2025 16:18:03 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Thu, 6 Mar 2025 01:25:37 -0800
> Cc: 76772 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > tags 76772 notabug
> > thanks
> >
> >> From: Artiom Balan <artiombalan331 <at> gmail.com>
> >> Date: Wed, 5 Mar 2025 23:47:26 +0200
> >>
> >> Steps to reproduce:
> >> 1. Run emacs: emacs -Q --eval "(display-warning 'type \"message\"))"
> >> 2. Notice the warning is displayed
> >> 3. Start emacs server: emacs -Q --fg-daemon --eval "(display-warning 'type \"message\"))"
> >> 4. Open a client: emacsclient -c
> >> 5. Notice the warning is not displayed
> >>
> >> I expected that the warnings buffer would be displayed in the exact
> >> same way in the emacsclient as in the first scenario.
> >
> > Thanks.
> >
> > The *Warnings* buffer is there, it's just that the client frame
> > doesn't show it.  Why should it? how should it know you want that
> > particular buffer displayed without any indication from you?
> 
> We show it unconditionally in regular Emacs sessions, so it is at the
> very least surprising that it is not displayed in the scenario described
> above.

When emacsclient connects, the new frame that it starts shows what
emacsclient tells the server to display, and if it doesn't, then the
default is the current buffer.  The server never displays anything
without being told, and emacsclient cannot know what were the
command-line arguments with which the daemon was invoked.

In general, the client frame shows what emacsclient tells it to show,
not something from the time the daemon started.

So I think the analogy cannot work, at least due to technical reasons
if not in principle.

Message #25 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Artiom Balan <artiombalan331 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76772 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76772: 29.4; Emacsclient doesn't display warnings emitted
 during daemon startup
Date: Thu, 6 Mar 2025 16:33:08 +0200

[Message part 1 (text/plain, inline)]

With the --eval I tried to simulate an error happening during the execution
of the init.el, for example.

I don't understand why it shouldn't be the case (at least in principle)
that the client automatically displays the warnings that were emitted
during the server startup. How else should you be notified of the warnings?
Are you supposed to remember to display it manually or hack your way around
it?

On Thu, Mar 6, 2025, 4:18 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Stefan Kangas <stefankangas <at> gmail.com>
> > Date: Thu, 6 Mar 2025 01:25:37 -0800
> > Cc: 76772 <at> debbugs.gnu.org
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > > tags 76772 notabug
> > > thanks
> > >
> > >> From: Artiom Balan <artiombalan331 <at> gmail.com>
> > >> Date: Wed, 5 Mar 2025 23:47:26 +0200
> > >>
> > >> Steps to reproduce:
> > >> 1. Run emacs: emacs -Q --eval "(display-warning 'type \"message\"))"
> > >> 2. Notice the warning is displayed
> > >> 3. Start emacs server: emacs -Q --fg-daemon --eval "(display-warning
> 'type \"message\"))"
> > >> 4. Open a client: emacsclient -c
> > >> 5. Notice the warning is not displayed
> > >>
> > >> I expected that the warnings buffer would be displayed in the exact
> > >> same way in the emacsclient as in the first scenario.
> > >
> > > Thanks.
> > >
> > > The *Warnings* buffer is there, it's just that the client frame
> > > doesn't show it.  Why should it? how should it know you want that
> > > particular buffer displayed without any indication from you?
> >
> > We show it unconditionally in regular Emacs sessions, so it is at the
> > very least surprising that it is not displayed in the scenario described
> > above.
>
> When emacsclient connects, the new frame that it starts shows what
> emacsclient tells the server to display, and if it doesn't, then the
> default is the current buffer.  The server never displays anything
> without being told, and emacsclient cannot know what were the
> command-line arguments with which the daemon was invoked.
>
> In general, the client frame shows what emacsclient tells it to show,
> not something from the time the daemon started.
>
> So I think the analogy cannot work, at least due to technical reasons
> if not in principle.
>

[Message part 2 (text/html, inline)]

Message #28 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Artiom Balan <artiombalan331 <at> gmail.com>
Cc: 76772 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#76772: 29.4; Emacsclient doesn't display warnings emitted
 during daemon startup
Date: Thu, 06 Mar 2025 16:42:46 +0200

> From: Artiom Balan <artiombalan331 <at> gmail.com>
> Date: Thu, 6 Mar 2025 16:33:08 +0200
> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 76772 <at> debbugs.gnu.org
> 
> With the --eval I tried to simulate an error happening during the execution of the init.el, for example. 

Understood.

> I don't understand why it shouldn't be the case (at least in principle) that the client automatically displays the
> warnings that were emitted during the server startup. How else should you be notified of the warnings? Are
> you supposed to remember to display it manually or hack your way around it? 

The client frames display messages and warnings triggered by showing
what emacsclient told the server to execute and show.  Anything else
needs to be explicitly requested to show on display, since the daemon
has no idea that the client connection is related in any way to the
message or warning or any other buffer Emacs pops due to what happened
in the server itself, _before_ the client connected.

Why is it a problem to look in *Messages* and *Warnings*, if you are
interested in any messages there?

Message #31 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Artiom Balan <artiombalan331 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76772 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#76772: 29.4; Emacsclient doesn't display warnings emitted
 during daemon startup
Date: Thu, 6 Mar 2025 16:53:59 +0200

[Message part 1 (text/plain, inline)]

> Why is it a problem to look in *Messages* and *Warnings*, if you are
interested in any messages there?

The problem is that warnings can pop up unexpectedly, and if you're not
automatically notified of them you will simply miss them.




On Thu, Mar 6, 2025, 4:43 PM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Artiom Balan <artiombalan331 <at> gmail.com>
> > Date: Thu, 6 Mar 2025 16:33:08 +0200
> > Cc: Stefan Kangas <stefankangas <at> gmail.com>, 76772 <at> debbugs.gnu.org
> >
> > With the --eval I tried to simulate an error happening during the
> execution of the init.el, for example.
>
> Understood.
>
> > I don't understand why it shouldn't be the case (at least in principle)
> that the client automatically displays the
> > warnings that were emitted during the server startup. How else should
> you be notified of the warnings? Are
> > you supposed to remember to display it manually or hack your way around
> it?
>
> The client frames display messages and warnings triggered by showing
> what emacsclient told the server to execute and show.  Anything else
> needs to be explicitly requested to show on display, since the daemon
> has no idea that the client connection is related in any way to the
> message or warning or any other buffer Emacs pops due to what happened
> in the server itself, _before_ the client connected.
>
> Why is it a problem to look in *Messages* and *Warnings*, if you are
> interested in any messages there?
>

[Message part 2 (text/html, inline)]

Message #34 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76772 <at> debbugs.gnu.org, artiombalan331 <at> gmail.com
Subject: Re: bug#76772: 29.4; Emacsclient doesn't display warnings emitted
 during daemon startup
Date: Fri, 7 Mar 2025 01:28:34 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Stefan Kangas <stefankangas <at> gmail.com>
>> Date: Thu, 6 Mar 2025 01:25:37 -0800
>> Cc: 76772 <at> debbugs.gnu.org
>>
>> Eli Zaretskii <eliz <at> gnu.org> writes:
>>
>> > tags 76772 notabug
>> > thanks
>> >
>> >> From: Artiom Balan <artiombalan331 <at> gmail.com>
>> >> Date: Wed, 5 Mar 2025 23:47:26 +0200
>> >>
>> >> Steps to reproduce:
>> >> 1. Run emacs: emacs -Q --eval "(display-warning 'type \"message\"))"
>> >> 2. Notice the warning is displayed
>> >> 3. Start emacs server: emacs -Q --fg-daemon --eval "(display-warning 'type \"message\"))"
>> >> 4. Open a client: emacsclient -c
>> >> 5. Notice the warning is not displayed
>> >>
>> >> I expected that the warnings buffer would be displayed in the exact
>> >> same way in the emacsclient as in the first scenario.
>> >
>> > Thanks.
>> >
>> > The *Warnings* buffer is there, it's just that the client frame
>> > doesn't show it.  Why should it? how should it know you want that
>> > particular buffer displayed without any indication from you?
>>
>> We show it unconditionally in regular Emacs sessions, so it is at the
>> very least surprising that it is not displayed in the scenario described
>> above.
>
> When emacsclient connects, the new frame that it starts shows what
> emacsclient tells the server to display, and if it doesn't, then the
> default is the current buffer.  The server never displays anything
> without being told, and emacsclient cannot know what were the
> command-line arguments with which the daemon was invoked.
>
> In general, the client frame shows what emacsclient tells it to show,
> not something from the time the daemon started.
>
> So I think the analogy cannot work, at least due to technical reasons
> if not in principle.

AFAIU, some people start emacs-server from, for example, systemd, and
only ever pop up an Emacs frame with emacsclient.  They might never see
the warnings.

If we expect people to manually check the *Warnings* buffer, this sounds
to me as the same as saying either
1. warnings are not important to display, or
2. warnings are not important to display to users that use
   emacs-server+emacsclient

If our reply is (2), which sounds more plausible, then I think that must
be justified somehow.

Message #37 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 76772 <at> debbugs.gnu.org, artiombalan331 <at> gmail.com
Subject: Re: bug#76772: 29.4; Emacsclient doesn't display warnings emitted
 during daemon startup
Date: Fri, 07 Mar 2025 09:33:24 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Fri, 7 Mar 2025 01:28:34 +0000
> Cc: artiombalan331 <at> gmail.com, 76772 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> > The *Warnings* buffer is there, it's just that the client frame
> >> > doesn't show it.  Why should it? how should it know you want that
> >> > particular buffer displayed without any indication from you?
> >>
> >> We show it unconditionally in regular Emacs sessions, so it is at the
> >> very least surprising that it is not displayed in the scenario described
> >> above.
> >
> > When emacsclient connects, the new frame that it starts shows what
> > emacsclient tells the server to display, and if it doesn't, then the
> > default is the current buffer.  The server never displays anything
> > without being told, and emacsclient cannot know what were the
> > command-line arguments with which the daemon was invoked.
> >
> > In general, the client frame shows what emacsclient tells it to show,
> > not something from the time the daemon started.
> >
> > So I think the analogy cannot work, at least due to technical reasons
> > if not in principle.
> 
> AFAIU, some people start emacs-server from, for example, systemd, and
> only ever pop up an Emacs frame with emacsclient.  They might never see
> the warnings.
> 
> If we expect people to manually check the *Warnings* buffer, this sounds
> to me as the same as saying either
> 1. warnings are not important to display, or
> 2. warnings are not important to display to users that use
>    emacs-server+emacsclient
> 
> If our reply is (2), which sounds more plausible, then I think that must
> be justified somehow.

If we want the first client connection to show the important messages
from the startup phase of the daemon, then warnings is not the only
thing, and not even the most important thing, that needs to be shown.
We should also show any errors and important echo-area messages, since
that's what the user will get when he/she starts Emacs normally with
the same init files and command-line arguments.  This requires some
infrastructure we don't currently have, AFAIK.  If you or someone else
want to work on such an infrastructure, I won't object to then using
it as part of the first client connection.  But talking only about
*Warnings* makes little sense to me, since displaying that upon the
first connection already needs some minimal infrastructure we don't
have, and if we are going to develop such infrastructure, let's do it
right from the get-go.

Message #40 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefankangas <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76772 <at> debbugs.gnu.org, artiombalan331 <at> gmail.com
Subject: Re: bug#76772: 29.4; Emacsclient doesn't display warnings emitted
 during daemon startup
Date: Fri, 7 Mar 2025 08:08:13 +0000

Eli Zaretskii <eliz <at> gnu.org> writes:

>> AFAIU, some people start emacs-server from, for example, systemd, and
>> only ever pop up an Emacs frame with emacsclient.  They might never see
>> the warnings.
>>
>> If we expect people to manually check the *Warnings* buffer, this sounds
>> to me as the same as saying either
>> 1. warnings are not important to display, or
>> 2. warnings are not important to display to users that use
>>    emacs-server+emacsclient
>>
>> If our reply is (2), which sounds more plausible, then I think that must
>> be justified somehow.
>
> If we want the first client connection to show the important messages
> from the startup phase of the daemon, then warnings is not the only
> thing, and not even the most important thing, that needs to be shown.
> We should also show any errors and important echo-area messages, since
> that's what the user will get when he/she starts Emacs normally with
> the same init files and command-line arguments.  This requires some
> infrastructure we don't currently have, AFAIK.  If you or someone else
> want to work on such an infrastructure, I won't object to then using
> it as part of the first client connection.  But talking only about
> *Warnings* makes little sense to me, since displaying that upon the
> first connection already needs some minimal infrastructure we don't
> have, and if we are going to develop such infrastructure, let's do it
> right from the get-go.

Fully agreed on all of the above.

This sounds to me like: patches welcome to implement the above.

Message #47 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Stefan Kangas <stefankangas <at> gmail.com>
Cc: 76772 <at> debbugs.gnu.org, artiombalan331 <at> gmail.com
Subject: Re: bug#76772: 29.4; Emacsclient doesn't display warnings emitted
 during daemon startup
Date: Fri, 07 Mar 2025 10:46:52 +0200

> From: Stefan Kangas <stefankangas <at> gmail.com>
> Date: Fri, 7 Mar 2025 08:08:13 +0000
> Cc: artiombalan331 <at> gmail.com, 76772 <at> debbugs.gnu.org
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> >> AFAIU, some people start emacs-server from, for example, systemd, and
> >> only ever pop up an Emacs frame with emacsclient.  They might never see
> >> the warnings.
> >>
> >> If we expect people to manually check the *Warnings* buffer, this sounds
> >> to me as the same as saying either
> >> 1. warnings are not important to display, or
> >> 2. warnings are not important to display to users that use
> >>    emacs-server+emacsclient
> >>
> >> If our reply is (2), which sounds more plausible, then I think that must
> >> be justified somehow.
> >
> > If we want the first client connection to show the important messages
> > from the startup phase of the daemon, then warnings is not the only
> > thing, and not even the most important thing, that needs to be shown.
> > We should also show any errors and important echo-area messages, since
> > that's what the user will get when he/she starts Emacs normally with
> > the same init files and command-line arguments.  This requires some
> > infrastructure we don't currently have, AFAIK.  If you or someone else
> > want to work on such an infrastructure, I won't object to then using
> > it as part of the first client connection.  But talking only about
> > *Warnings* makes little sense to me, since displaying that upon the
> > first connection already needs some minimal infrastructure we don't
> > have, and if we are going to develop such infrastructure, let's do it
> > right from the get-go.
> 
> Fully agreed on all of the above.
> 
> This sounds to me like: patches welcome to implement the above.

Yes.

Message #50 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Artiom Balan <artiombalan331 <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 76772 <at> debbugs.gnu.org, Stefan Kangas <stefankangas <at> gmail.com>
Subject: Re: bug#76772: 29.4; Emacsclient doesn't display warnings emitted
 during daemon startup
Date: Sat, 8 Mar 2025 10:53:38 +0200

[Message part 1 (text/plain, inline)]

> But talking only about
> *Warnings* makes little sense to me, since displaying that upon the
> first connection already needs some minimal infrastructure we don't
> have, and if we are going to develop such infrastructure, let's do it
> right from the get-go.

I see you're a proponent of consistency and doing the right thing ;)

> If we want the first client connection to show the important messages
> from the startup phase of the daemon, then warnings is not the only
> thing, and not even the most important thing, that needs to be shown.

Good point. To generalize, is the only difference between running a regular
emacs instance and running an emacs daemon the fact that the user doesn't
see some things? Like, the behavior is the same, but some things are
"shown" in the daemon, which the user can't see. If so, how can we know
which are all of these things? You added errors and echo-area messages. Are
there any others?

Would the ideal solution be to show in the first emacsclient everything
that the regular instance would have shown? Or maybe a hack that displays
the warnings (and errors?) in the first emacsclient would suffice?

BTW, how can i get emacs to show errors after startup? I tried to add a
`(error "message")` to my init.el, and starting emacs would show it as a
warning:
"Warning (initialization): An error occurred while loading ..."

> AFAIU, some people start emacs-server from, for example, systemd, and
> only ever pop up an Emacs frame with emacsclient.  They might never see
> the warnings.

Yes, that's how I do it. It's interesting that you could also start the
server by first starting emacs regularly, and then running (server-start).
I might consider trying this out.

On Fri, Mar 7, 2025 at 10:46 AM Eli Zaretskii <eliz <at> gnu.org> wrote:

> > From: Stefan Kangas <stefankangas <at> gmail.com>
> > Date: Fri, 7 Mar 2025 08:08:13 +0000
> > Cc: artiombalan331 <at> gmail.com, 76772 <at> debbugs.gnu.org
> >
> > Eli Zaretskii <eliz <at> gnu.org> writes:
> >
> > >> AFAIU, some people start emacs-server from, for example, systemd, and
> > >> only ever pop up an Emacs frame with emacsclient.  They might never
> see
> > >> the warnings.
> > >>
> > >> If we expect people to manually check the *Warnings* buffer, this
> sounds
> > >> to me as the same as saying either
> > >> 1. warnings are not important to display, or
> > >> 2. warnings are not important to display to users that use
> > >>    emacs-server+emacsclient
> > >>
> > >> If our reply is (2), which sounds more plausible, then I think that
> must
> > >> be justified somehow.
> > >
> > > If we want the first client connection to show the important messages
> > > from the startup phase of the daemon, then warnings is not the only
> > > thing, and not even the most important thing, that needs to be shown.
> > > We should also show any errors and important echo-area messages, since
> > > that's what the user will get when he/she starts Emacs normally with
> > > the same init files and command-line arguments.  This requires some
> > > infrastructure we don't currently have, AFAIK.  If you or someone else
> > > want to work on such an infrastructure, I won't object to then using
> > > it as part of the first client connection.  But talking only about
> > > *Warnings* makes little sense to me, since displaying that upon the
> > > first connection already needs some minimal infrastructure we don't
> > > have, and if we are going to develop such infrastructure, let's do it
> > > right from the get-go.
> >
> > Fully agreed on all of the above.
> >
> > This sounds to me like: patches welcome to implement the above.
>
> Yes.
>

[Message part 2 (text/html, inline)]

Message #53 received at 76772 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Artiom Balan <artiombalan331 <at> gmail.com>
Cc: 76772 <at> debbugs.gnu.org, stefankangas <at> gmail.com
Subject: Re: bug#76772: 29.4; Emacsclient doesn't display warnings emitted
 during daemon startup
Date: Sun, 09 Mar 2025 12:35:51 +0200

> From: Artiom Balan <artiombalan331 <at> gmail.com>
> Date: Sat, 8 Mar 2025 10:53:38 +0200
> Cc: Stefan Kangas <stefankangas <at> gmail.com>, 76772 <at> debbugs.gnu.org
> 
> > If we want the first client connection to show the important messages
> > from the startup phase of the daemon, then warnings is not the only
> > thing, and not even the most important thing, that needs to be shown.
> 
> Good point. To generalize, is the only difference between running a regular emacs instance and running an
> emacs daemon the fact that the user doesn't see some things? Like, the behavior is the same, but some
> things are "shown" in the daemon, which the user can't see. If so, how can we know which are all of these
> things? You added errors and echo-area messages. Are there any others?

When some code in Emacs shows a message, we don't usually make sure
the message is displayed.  We call the usual functions like 'message'
or pop-to-buffer, and if the selected frame is not shown on display,
we leave it at that.

So in general, the daemon doesn't show anything, with the exception of
critical problems that prevent it from starting (those are written to
stderr of the controlling terminal at the moment of daemon startup).

> Would the ideal solution be to show in the first emacsclient everything that the regular instance would have
> shown? Or maybe a hack that displays the warnings (and errors?) in the first emacsclient would suffice? 

I think we should have some way of deferring messages until some frame
is visible on display.

> BTW, how can i get emacs to show errors after startup? I tried to add a `(error "message")` to my init.el, and
> starting emacs would show it as a warning: 
> "Warning (initialization): An error occurred while loading ..."

Signaling an error during startup prevents Emacs from starting, so the
user will not see any messages at all, which is not useful.
Therefore, Emacs handles errors during startup in a special way.  If
you want Emacs to enter a debugger due to problem in startup and/or
init files, use the --debug-init command-line option to start Emacs.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.