bug#63181: 28.2; Can't suppress server-already-running warning

[Eli Zaretskii <eliz@gnu.org>]

> From: Dave Abrahams <dave@boostpro.com>
> Date: Mon, 1 May 2023 09:24:10 -0700
> Cc: 63181@debbugs.gnu.org
> 
> > Did you try my other suggestions? did they work? can we close this bug
> > report?
> 
> This works for me:
> 
> ;;
> ;; Start the server, suppressing warnings
> ;;
> ;; I often run a 2nd emacs especially when working on configuration,
> ;; and I don't like startup to be noisy.  But the suppression doesn't
> ;; work unless I defer the work because warning processing is
> ;; deferred until after startup; see
> ;; https://debbugs.gnu.org/cgi/bugreport.cgi?bug=63181
> (add-hook 'emacs-startup-hook
> 	  (lambda ()
> 	    (dlet ((warning-suppress-types '((server))))
> 	      (server-mode))))

That's a good solution, thanks.

> Whether to close the bug is up to you of course, but IMO there's still a problem, at *least* in documentation.  Ideally the value of warning-suppress-types should be respected at the time warnings are queued, but if not, the documentation should be updated with a caveat about trying to use it during startup.  But really, who wants more caveats? ;-)

The documentation was already fixed to mention this caveat and the
proposed solutions, as you will find if you look at the emacs-29
branch of the Emacs Git repository.

More generally, I think it's unreasonable to assume that every
let-binding takes effect for everything that is triggered inside the
body of the binding.  A prominent example where this is not true is
when the body triggers some display-related feature -- the binding
doesn't work in that case because redisplay happens later, after the
command performed its thing and returned to the Emacs main loop.  In
addition, problems during startup are notoriously hard to detect and
debug if their warnings are suppressed, so I think it's completely
okay if suppressing them is not really easy.

So I don't think we have anything else to do here aside of documenting
the fact that warnings are delayed during startup, and so I'm closing
this bug.