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