Subject: Re: bug#76772: 29.4; Emacsclient doesn't display warnings emitted during daemon startup

From: Eli Zaretskii <[email-masked]>
Date: Fri, 07 Mar 2025 09:33:24 +0200

> From: Stefan Kangas <[email-masked]>
> Date: Fri, 7 Mar 2025 01:28:34 +0000
> Cc: [email-masked], [email-masked]
> 
> Eli Zaretskii <[email-masked]> 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.