bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Dave Abrahams
Subject: bug#63181: 28.2; Can't suppress server-already-running warning
Date: Mon, 1 May 2023 09:24:10 -0700


> On May 1, 2023, at 8:54 AM, Eli Zaretskii <eliz@gnu.org> wrote:
> 
>> From: Dave Abrahams <dave@boostpro.com>
>> Date: Mon, 1 May 2023 08:27:46 -0700
>> Cc: 63181@debbugs.gnu.org
>> 
>> I let-bind because I don’t want to suppress all server warnings forever, 
>> which is what I presume adding ‘sever to the list means ; just this one. 
>> Thanks for the explanation 
> 
> If you want to suppress these warnings only during startup, you can
> restore the original value of warning-suppress-types in
> emacs-startup-hook.

Saving and restoring this thing manually seems very inelegant compared with 
allowing `let' to do what it's designed for, and I don't want to globally 
override 

I should point out that I wasn't presuming that warnings would be issued 
immediately, only that the setting of warning-suppress-types would be examined 
in whichever function was responsible for queueing warnings, rather than (only) 
the code that reports them.

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

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? ;-)






reply via email to

[Prev in Thread] Current Thread [Next in Thread]