native-comp *Warnings* buffer

native-comp *Warnings* buffer

[Eric Abrahamsen]

I understand the utility of having these warnings, but does the buffer
need to be popped up every thirty seconds? Couldn't it just be displayed
once, when it's created, and then left alone? Compilation has been going
on for several minutes since rebuilding Emacs, and it's actually hard to
use with *Warnings* occupying my other window every few seconds!

Thanks,
Eric

Re: native-comp *Warnings* buffer

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I understand the utility of having these warnings, but does the buffer
> need to be popped up every thirty seconds? Couldn't it just be displayed
> once, when it's created, and then left alone? Compilation has been going
> on for several minutes since rebuilding Emacs, and it's actually hard to
> use with *Warnings* occupying my other window every few seconds!

I should say that I know about
`native-comp-async-report-warnings-errors', and I'd actually like to see
these warnings (as many of them are about my own code :(), I'd just like
to have them in the background.

Re: native-comp *Warnings* buffer

[Andrea Corallo via Emacs development discussions.]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> I understand the utility of having these warnings, but does the buffer
>> need to be popped up every thirty seconds? Couldn't it just be displayed
>> once, when it's created, and then left alone? Compilation has been going
>> on for several minutes since rebuilding Emacs, and it's actually hard to
>> use with *Warnings* occupying my other window every few seconds!
>
> I should say that I know about
> `native-comp-async-report-warnings-errors', and I'd actually like to see
> these warnings (as many of them are about my own code :(), I'd just like
> to have them in the background.

Hi Eric,

unfortunately new warnings are showed when they are found while
compiling.  I agree this is annoying but at the same time I'm not sure
this behavior wrong.

Anyway in comp.el we just call `display-warning'.  If there's a better
way to handle this any suggestion or patch is very welcome :)

Thanks

  Andrea

Re: native-comp *Warnings* buffer

[Eric Abrahamsen]

Andrea Corallo via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> I understand the utility of having these warnings, but does the buffer
>>> need to be popped up every thirty seconds? Couldn't it just be displayed
>>> once, when it's created, and then left alone? Compilation has been going
>>> on for several minutes since rebuilding Emacs, and it's actually hard to
>>> use with *Warnings* occupying my other window every few seconds!
>>
>> I should say that I know about
>> `native-comp-async-report-warnings-errors', and I'd actually like to see
>> these warnings (as many of them are about my own code :(), I'd just like
>> to have them in the background.
>
> Hi Eric,
>
> unfortunately new warnings are showed when they are found while
> compiling.  I agree this is annoying but at the same time I'm not sure
> this behavior wrong.
>
> Anyway in comp.el we just call `display-warning'.  If there's a better
> way to handle this any suggestion or patch is very welcome :)

It looks like `warning-suppress-types' might do it!

List of warning types not to display immediately.
If any element of this list matches the TYPE argument to ‘display-warning’,
the warning is logged nonetheless, but the warnings buffer is
not immediately displayed.
The element must match an initial segment of the list TYPE.
Thus, (foo bar) as an element matches (foo bar)
or (foo bar ANYTHING...) as TYPE.
If TYPE is a symbol FOO, that is equivalent to the list (FOO),
so only the element (FOO) will match it.

Let-binding this with 'comp in the value should do it.

We could add 'suppress or 'quiet as an alternate value
`native-comp-async-report-warnings-errors', and use that to optionally
change the value of `warning-suppress-types'.

Re: native-comp *Warnings* buffer

[Eric Abrahamsen]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Andrea Corallo via "Emacs development discussions."
> <emacs-devel@gnu.org> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>>
>>>> I understand the utility of having these warnings, but does the buffer
>>>> need to be popped up every thirty seconds? Couldn't it just be displayed
>>>> once, when it's created, and then left alone? Compilation has been going
>>>> on for several minutes since rebuilding Emacs, and it's actually hard to
>>>> use with *Warnings* occupying my other window every few seconds!
>>>
>>> I should say that I know about
>>> `native-comp-async-report-warnings-errors', and I'd actually like to see
>>> these warnings (as many of them are about my own code :(), I'd just like
>>> to have them in the background.
>>
>> Hi Eric,
>>
>> unfortunately new warnings are showed when they are found while
>> compiling.  I agree this is annoying but at the same time I'm not sure
>> this behavior wrong.
>>
>> Anyway in comp.el we just call `display-warning'.  If there's a better
>> way to handle this any suggestion or patch is very welcome :)
>
> It looks like `warning-suppress-types' might do it!
>
> List of warning types not to display immediately.
> If any element of this list matches the TYPE argument to ‘display-warning’,
> the warning is logged nonetheless, but the warnings buffer is
> not immediately displayed.
> The element must match an initial segment of the list TYPE.
> Thus, (foo bar) as an element matches (foo bar)
> or (foo bar ANYTHING...) as TYPE.
> If TYPE is a symbol FOO, that is equivalent to the list (FOO),
> so only the element (FOO) will match it.
>
> Let-binding this with 'comp in the value should do it.
>
> We could add 'suppress or 'quiet as an alternate value
> `native-comp-async-report-warnings-errors', and use that to optionally
> change the value of `warning-suppress-types'.

Well I guess I could have figured this out myself: the clickable
"Disable showing" button at the end of every warning does exactly this:
customizes `warning-suppress-types' so that the '(comp) warnings are
still logged to *Warnings*, but it doesn't pop up the buffer. This seems
like enough customization to me, and there's no need to add any code!

Actually it looks like `native-comp-async-report-warnings-errors' could
be replaced by customization of `warning-suppress-log-types', which will
prevent logging altogether. Anyway, problem solved!

Re: native-comp *Warnings* buffer

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1762 bytes --]

Andrea Corallo via "Emacs development discussions."
<emacs-devel@gnu.org> writes:


Lacking a better solution, I implemented myself an after advice on
display-warning that buries the buffer and produces a soft sound to let
me know that a warning got added; then I just go visit that buffer when
I have some cycles to see what raised the warning, and whether it is in
my code, how to fix it etc.

One issue with the warnings is that the reported line  that triggered
the warning tends to  be one or two indirections removed (eg via require
 etc) which makes finding the actual cause fairly  difficult for now > Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>>
>>> I understand the utility of having these warnings, but does the buffer
>>> need to be popped up every thirty seconds? Couldn't it just be displayed
>>> once, when it's created, and then left alone? Compilation has been going
>>> on for several minutes since rebuilding Emacs, and it's actually hard to
>>> use with *Warnings* occupying my other window every few seconds!
>>
>> I should say that I know about
>> `native-comp-async-report-warnings-errors', and I'd actually like to see
>> these warnings (as many of them are about my own code :(), I'd just like
>> to have them in the background.
>
> Hi Eric,
>
> unfortunately new warnings are showed when they are found while
> compiling.  I agree this is annoying but at the same time I'm not sure
> this behavior wrong.
>
> Anyway in comp.el we just call `display-warning'.  If there's a better
> way to handle this any suggestion or patch is very welcome :)
>
> Thanks
>
>   Andrea
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: native-comp *Warnings* buffer

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Thu, 13 May 2021 12:59:12 -0700
> 
> I understand the utility of having these warnings, but does the buffer
> need to be popped up every thirty seconds?

It only pops up if you delete the window, doesn't it?  So in what
sense is it different from what we do with the *Compilation* buffer?

Re: native-comp *Warnings* buffer

[Eli Zaretskii]

> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Thu, 13 May 2021 14:34:40 -0700
> Cc: Andrea Corallo <akrl@sdf.org>
> 
> We could add 'suppress or 'quiet as an alternate value
> `native-comp-async-report-warnings-errors', and use that to optionally
> change the value of `warning-suppress-types'.

Yes, this could be a good feature, for those who want this deferral up
front, not via the buttons already present.

Re: native-comp *Warnings* buffer

[Eli Zaretskii]

> From: "T.V Raman" <raman@google.com>
> Cc: Eric Abrahamsen <eric@ericabrahamsen.net>,  Andrea Corallo <akrl@sdf.org>
> Date: Thu, 13 May 2021 19:30:17 -0700
> 
> Lacking a better solution, I implemented myself an after advice on
> display-warning that buries the buffer and produces a soft sound to let
> me know that a warning got added; then I just go visit that buffer when
> I have some cycles to see what raised the warning, and whether it is in
> my code, how to fix it etc.

May I suggest that you report these issues instead of (or in addition
to) working around them in your Emacs?  Especially when these problems
are from a development version, we need help from everyone who uses
that version to stabilize it as quickly as possible.  We cannot do
that efficiently if people solve the issues privately without telling
us.

TIA.

Re: native-comp *Warnings* buffer

[Eric Abrahamsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Thu, 13 May 2021 12:59:12 -0700
>> 
>> I understand the utility of having these warnings, but does the buffer
>> need to be popped up every thirty seconds?
>
> It only pops up if you delete the window, doesn't it?  So in what
> sense is it different from what we do with the *Compilation* buffer?

I guess usage. I only see the *Compilation* buffer when I've
done something to ask for it (updating packages, etc), and it's over
relatively quickly. These warnings went on for many long minutes, at
random intervals. I was trying to work in two side-by-side buffers, and
it kept stealing the other one -- I even switched frames once the
*Warnings* buffer was open, but it followed me to the new frame.

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Thu, 13 May 2021 14:34:40 -0700
>> Cc: Andrea Corallo <akrl@sdf.org>
>> 
>> We could add 'suppress or 'quiet as an alternate value
>> `native-comp-async-report-warnings-errors', and use that to optionally
>> change the value of `warning-suppress-types'.
>
> Yes, this could be a good feature, for those who want this deferral up
> front, not via the buttons already present.

I could do a patch for that, but the existing mechanisms *are* pretty
thorough: big prominent buttons that do exactly what they promise to do
(I'm a bit embarrassed I didn't just read the instructions).

Re: native-comp *Warnings* buffer

[Stefan Monnier]

> I guess usage. I only see the *Compilation* buffer when I've
> done something to ask for it (updating packages, etc), and it's over
> relatively quickly. These warnings went on for many long minutes, at
> random intervals. I was trying to work in two side-by-side buffers, and
> it kept stealing the other one -- I even switched frames once the
> *Warnings* buffer was open, but it followed me to the new frame.

I think "stealth" compilation performed opportunistically in the
background should indeed not display any warnings (by default).

> I could do a patch for that, but the existing mechanisms *are* pretty
> thorough: big prominent buttons that do exactly what they promise to do
> (I'm a bit embarrassed I didn't just read the instructions).

Don't those buttons also suppress the warnings for the normal
(non-async, non-native) compilation case?  If so, we should be careful
not to encourage the users to do that when they're only annoyed by the
async warnings.


        Stefan

Re: native-comp *Warnings* buffer

[Eric Abrahamsen]

On May 14, 2021 9:23:50 AM PDT, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> I guess usage. I only see the *Compilation* buffer when I've
>> done something to ask for it (updating packages, etc), and it's over
>> relatively quickly. These warnings went on for many long minutes, at
>> random intervals. I was trying to work in two side-by-side buffers,
>and
>> it kept stealing the other one -- I even switched frames once the
>> *Warnings* buffer was open, but it followed me to the new frame.
>
>I think "stealth" compilation performed opportunistically in the
>background should indeed not display any warnings (by default).
>
>> I could do a patch for that, but the existing mechanisms *are* pretty
>> thorough: big prominent buttons that do exactly what they promise to
>do
>> (I'm a bit embarrassed I didn't just read the instructions).
>
>Don't those buttons also suppress the warnings for the normal
>(non-async, non-native) compilation case?  If so, we should be careful
>not to encourage the users to do that when they're only annoyed by the
>async warnings.

The buttons will add '(comp) to the list of suppressed warnings, so no warnings with that tag would ever be popped-up, in any context. I'm not sure what else uses that tag (I'm on my phone right now) but yes, that might be a little drastic.

Re: native-comp *Warnings* buffer

[Eric Abrahamsen]

On May 14, 2021 9:46:41 AM PDT, Eric Abrahamsen <eric@ericabrahamsen.net> wrote:
>
>
>On May 14, 2021 9:23:50 AM PDT, Stefan Monnier
><monnier@iro.umontreal.ca> wrote:
>>> I guess usage. I only see the *Compilation* buffer when I've
>>> done something to ask for it (updating packages, etc), and it's over
>>> relatively quickly. These warnings went on for many long minutes, at
>>> random intervals. I was trying to work in two side-by-side buffers,
>>and
>>> it kept stealing the other one -- I even switched frames once the
>>> *Warnings* buffer was open, but it followed me to the new frame.
>>
>>I think "stealth" compilation performed opportunistically in the
>>background should indeed not display any warnings (by default).
>>
>>> I could do a patch for that, but the existing mechanisms *are*
>pretty
>>> thorough: big prominent buttons that do exactly what they promise to
>>do
>>> (I'm a bit embarrassed I didn't just read the instructions).
>>
>>Don't those buttons also suppress the warnings for the normal
>>(non-async, non-native) compilation case?  If so, we should be careful
>>not to encourage the users to do that when they're only annoyed by the
>>async warnings.
>
>The buttons will add '(comp) to the list of suppressed warnings, so no
>warnings with that tag would ever be popped-up, in any context. I'm not
>sure what else uses that tag (I'm on my phone right now) but yes, that
>might be a little drastic.

If anyone else does use 'comp, we could have comp.el use '(comp async), which seems nicely targeted.

Re: native-comp *Warnings* buffer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > I think "stealth" compilation performed opportunistically in the
  > background should indeed not display any warnings (by default).

I understand the reason for saying that, but... would this mean that a
compilation of that meaterial won't happen later?  Is there a chance
that you'll never see the warnings that compilation generates?

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: native-comp *Warnings* buffer

[Eric Abrahamsen]

[-- Attachment #1: Type: text/plain, Size: 1071 bytes --]

Richard Stallman <rms@gnu.org> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > I think "stealth" compilation performed opportunistically in the
>   > background should indeed not display any warnings (by default).
>
> I understand the reason for saying that, but... would this mean that a
> compilation of that meaterial won't happen later?  Is there a chance
> that you'll never see the warnings that compilation generates?

This wouldn't affect the actual compilation at all. It could affect
whether the user sees the warnings or not, if we default to not popping
up the *Warnings* buffer. They might still go looking for the buffer, or
stumble upon it by accident, though.

I've attached a patch that provides a 'silent option to
`native-comp-async-report-warnings-errors'. In this patch the default is
still t, though we could easily default to 'silent if that seems
desirable.


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Provide-a-silent-option-for-native-comp-asyncreport-.patch --]
[-- Type: text/x-patch, Size: 2788 bytes --]

From 01516b21e71862f3496e3a1f75bb86d436afaa3b Mon Sep 17 00:00:00 2001
From: Eric Abrahamsen <eric@ericabrahamsen.net>
Date: Sat, 15 May 2021 09:36:05 -0700
Subject: [PATCH] Provide a 'silent option for
 native-comp-asyncreport-warnings-errors

* lisp/emacs-lisp/comp.el (native-comp-async-report-warnings-errors):
Set to 'silent to log warnings, but not pop up the *Warnings* buffer.
* lisp/emacs-lisp/comp.el (comp-accept-and-process-async-output):
Check value.
---
 lisp/emacs-lisp/comp.el | 29 +++++++++++++++++++----------
 1 file changed, 19 insertions(+), 10 deletions(-)

diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
index 3e7f17ef1c..8fa9dee1ed 100644
--- a/lisp/emacs-lisp/comp.el
+++ b/lisp/emacs-lisp/comp.el
@@ -148,8 +148,13 @@ native-comp-async-report-warnings-errors
 environment, it is more sensitive to such omissions, and might be
 unable to compile such Lisp source files correctly.
 
-Set this variable to nil if these warnings annoy you."
-  :type 'boolean
+Set this variable to nil to suppress warnings altogether, or to
+the symbol `quiet' to log warnings but not pop up the *Warnings*
+buffer."
+  :type '(choice
+          (const :tag "Do not report warnings" nil)
+          (const :tag "Report and display warnings" t)
+          (const :tag "Report but do not display warnings" 'silent))
   :version "28.1")
 
 (defcustom native-comp-async-query-on-exit nil
@@ -3874,14 +3879,18 @@ comp-last-scanned-async-output
 (defun comp-accept-and-process-async-output (process)
   "Accept PROCESS output and check for diagnostic messages."
   (if native-comp-async-report-warnings-errors
-      (with-current-buffer (process-buffer process)
-        (save-excursion
-          (accept-process-output process)
-          (goto-char (or comp-last-scanned-async-output (point-min)))
-          (while (re-search-forward "^.*?\\(?:Error\\|Warning\\): .*$"
-                                    nil t)
-            (display-warning 'comp (match-string 0)))
-          (setq comp-last-scanned-async-output (point-max))))
+      (let ((warning-suppress-types
+             (if (eq native-comp-async-report-warnings-errors 'silent)
+                 (cons '(comp) warning-suppress-types)
+               warning-suppress-types)))
+        (with-current-buffer (process-buffer process)
+          (save-excursion
+            (accept-process-output process)
+            (goto-char (or comp-last-scanned-async-output (point-min)))
+            (while (re-search-forward "^.*?\\(?:Error\\|Warning\\): .*$"
+                                      nil t)
+              (display-warning 'comp (match-string 0)))
+            (setq comp-last-scanned-async-output (point-max)))))
     (accept-process-output process)))
 
 (defun comp-run-async-workers ()
-- 
2.31.1

Re: native-comp *Warnings* buffer

[Stefan Monnier]

>   > I think "stealth" compilation performed opportunistically in the
>   > background should indeed not display any warnings (by default).
> I understand the reason for saying that, but... would this mean that a
> compilation of that material won't happen later?

No, the compilation must have happened *before*, because native
compilation is only performed for files that are compiled to
`.elc`, AFAIK.

> Is there a chance that you'll never see the warnings that
> compilation generates?

AFAIK, no, because before native compilation takes place, the code will
already have been byte-compiled.


        Stefan

Re: native-comp *Warnings* buffer

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: eric@ericabrahamsen.net,  emacs-devel@gnu.org
> Date: Sun, 16 May 2021 01:12:49 -0400
> 
> >   > I think "stealth" compilation performed opportunistically in the
> >   > background should indeed not display any warnings (by default).
> > I understand the reason for saying that, but... would this mean that a
> > compilation of that material won't happen later?
> 
> No, the compilation must have happened *before*, because native
> compilation is only performed for files that are compiled to
> `.elc`, AFAIK.
> 
> > Is there a chance that you'll never see the warnings that
> > compilation generates?
> 
> AFAIK, no, because before native compilation takes place, the code will
> already have been byte-compiled.

I think it actually could happen if the relevant *.el files are
modified during the session and then recompiled or reloaded.

Re: native-comp *Warnings* buffer

[Stefan Monnier]

>> AFAIK, no, because before native compilation takes place, the code will
>> already have been byte-compiled.
> I think it actually could happen if the relevant *.el files are
> modified during the session and then recompiled or reloaded.

If so, we'll need to address that, indeed.

But currently, the warnings we get from async native compilation are
both annoying and redundant in almost all cases, so I think that
silencing them is a good "first cut".
[ Tho I don't mind keeping them enabled for now on `master`: it only
  needs to be fixed "some time" before the release and I don't think
  there's a particular hurry.  ]


        Stefan

Jump to source of warning was Re: native-comp *Warnings* buffer

[T.V Raman]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset=gb18030, Size: 1383 bytes --]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:


Re the Warnings buffer, would it be possible to add a button that jumps
to the place in the elisp source that produced the warning?

> Richard Stallman <rms@gnu.org> writes:
>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>   > I think "stealth" compilation performed opportunistically in the
>>   > background should indeed not display any warnings (by default).
>>
>> I understand the reason for saying that, but... would this mean that a
>> compilation of that meaterial won't happen later?  Is there a chance
>> that you'll never see the warnings that compilation generates?
>
> This wouldn't affect the actual compilation at all. It could affect
> whether the user sees the warnings or not, if we default to not popping
> up the *Warnings* buffer. They might still go looking for the buffer, or
> stumble upon it by accident, though.
>
> I've attached a patch that provides a 'silent option to
> `native-comp-async-report-warnings-errors'. In this patch the default is
> still t, though we could easily default to 'silent if that seems
> desirable.
>
>

-- 

Thanks,

--Raman
7©4 Id: kg:/m/0285kf1  •0Ü8

Re: native-comp *Warnings* buffer

[Andrea Corallo via Emacs development discussions.]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>> [[[ whether defending the US Constitution against all enemies,     ]]]
>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>
>>   > I think "stealth" compilation performed opportunistically in the
>>   > background should indeed not display any warnings (by default).
>>
>> I understand the reason for saying that, but... would this mean that a
>> compilation of that meaterial won't happen later?  Is there a chance
>> that you'll never see the warnings that compilation generates?
>
> This wouldn't affect the actual compilation at all. It could affect
> whether the user sees the warnings or not, if we default to not popping
> up the *Warnings* buffer. They might still go looking for the buffer, or
> stumble upon it by accident, though.
>
> I've attached a patch that provides a 'silent option to
> `native-comp-async-report-warnings-errors'. In this patch the default is
> still t, though we could easily default to 'silent if that seems
> desirable.

Hi Eric,

thanks for the patch, it sounds like a good idea.

Just a small nit below otherwise LGTM.

>>From 01516b21e71862f3496e3a1f75bb86d436afaa3b Mon Sep 17 00:00:00 2001
> From: Eric Abrahamsen <eric@ericabrahamsen.net>
> Date: Sat, 15 May 2021 09:36:05 -0700
> Subject: [PATCH] Provide a 'silent option for
>  native-comp-asyncreport-warnings-errors
>
> * lisp/emacs-lisp/comp.el (native-comp-async-report-warnings-errors):
> Set to 'silent to log warnings, but not pop up the *Warnings* buffer.
> * lisp/emacs-lisp/comp.el (comp-accept-and-process-async-output):
> Check value.
> ---
>  lisp/emacs-lisp/comp.el | 29 +++++++++++++++++++----------
>  1 file changed, 19 insertions(+), 10 deletions(-)
>
> diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
> index 3e7f17ef1c..8fa9dee1ed 100644
> --- a/lisp/emacs-lisp/comp.el
> +++ b/lisp/emacs-lisp/comp.el
> @@ -148,8 +148,13 @@ native-comp-async-report-warnings-errors
>  environment, it is more sensitive to such omissions, and might be
>  unable to compile such Lisp source files correctly.
>  
> -Set this variable to nil if these warnings annoy you."
> -  :type 'boolean
> +Set this variable to nil to suppress warnings altogether, or to
> +the symbol `quiet' to log warnings but not pop up the *Warnings*
              ^^^
              `silent'?
> +buffer."
> +  :type '(choice
> +          (const :tag "Do not report warnings" nil)
> +          (const :tag "Report and display warnings" t)
> +          (const :tag "Report but do not display warnings" 'silent))
>    :version "28.1")

[...]

Thanks

  Andrea

Re: native-comp *Warnings* buffer

[Eric Abrahamsen]

Andrea Corallo via "Emacs development discussions."
<emacs-devel@gnu.org> writes:

> Eric Abrahamsen <eric@ericabrahamsen.net> writes:
>
>> Richard Stallman <rms@gnu.org> writes:
>>
>>> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
>>> [[[ whether defending the US Constitution against all enemies,     ]]]
>>> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>>>
>>>   > I think "stealth" compilation performed opportunistically in the
>>>   > background should indeed not display any warnings (by default).
>>>
>>> I understand the reason for saying that, but... would this mean that a
>>> compilation of that meaterial won't happen later?  Is there a chance
>>> that you'll never see the warnings that compilation generates?
>>
>> This wouldn't affect the actual compilation at all. It could affect
>> whether the user sees the warnings or not, if we default to not popping
>> up the *Warnings* buffer. They might still go looking for the buffer, or
>> stumble upon it by accident, though.
>>
>> I've attached a patch that provides a 'silent option to
>> `native-comp-async-report-warnings-errors'. In this patch the default is
>> still t, though we could easily default to 'silent if that seems
>> desirable.
>
> Hi Eric,
>
> thanks for the patch, it sounds like a good idea.
>
> Just a small nit below otherwise LGTM.
>
>>>From 01516b21e71862f3496e3a1f75bb86d436afaa3b Mon Sep 17 00:00:00 2001
>> From: Eric Abrahamsen <eric@ericabrahamsen.net>
>> Date: Sat, 15 May 2021 09:36:05 -0700
>> Subject: [PATCH] Provide a 'silent option for
>>  native-comp-asyncreport-warnings-errors
>>
>> * lisp/emacs-lisp/comp.el (native-comp-async-report-warnings-errors):
>> Set to 'silent to log warnings, but not pop up the *Warnings* buffer.
>> * lisp/emacs-lisp/comp.el (comp-accept-and-process-async-output):
>> Check value.
>> ---
>>  lisp/emacs-lisp/comp.el | 29 +++++++++++++++++++----------
>>  1 file changed, 19 insertions(+), 10 deletions(-)
>>
>> diff --git a/lisp/emacs-lisp/comp.el b/lisp/emacs-lisp/comp.el
>> index 3e7f17ef1c..8fa9dee1ed 100644
>> --- a/lisp/emacs-lisp/comp.el
>> +++ b/lisp/emacs-lisp/comp.el
>> @@ -148,8 +148,13 @@ native-comp-async-report-warnings-errors
>>  environment, it is more sensitive to such omissions, and might be
>>  unable to compile such Lisp source files correctly.
>>  
>> -Set this variable to nil if these warnings annoy you."
>> -  :type 'boolean
>> +Set this variable to nil to suppress warnings altogether, or to
>> +the symbol `quiet' to log warnings but not pop up the *Warnings*
>               ^^^
>               `silent'?

Whoops! I went back and forth on the symbol to use, and apparently
settled on "borth". Thanks.

I forgot to say, I only put this check on one of the three
`display-warning' call-sites in this file, because the others looked
like fairly specific situations that the user should be bothered about.
If they should all have it, I can do that, too.

Eric

Re: native-comp *Warnings* buffer

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

  > This wouldn't affect the actual compilation at all. It could affect
  > whether the user sees the warnings or not, if we default to not popping
  > up the *Warnings* buffer. They might still go looking for the buffer, or
  > stumble upon it by accident, though.

Yes, that's exactly the issue.

If you were going to have a compilation of foo.el based on some
explicit request, and therefore see its warnings then,
anything that compiles it by anticipation
and does not show you its warnings
could cause that explicit request NOT to compile it
(because it was compiled recently), and therefore you
would never see its warnings.

Most of the time this would not matter at all.
However, on rare occasions it could cause a real problem.
Perhaps even a serious one.

So I think it is important to make sure this scenario -- suppressing
a warning you would have been shown -- cannot happen.

There are many ways to do that.  My concern is simply that it be done,
one way or another.

-- 
Dr Richard Stallman (https://stallman.org)
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: native-comp *Warnings* buffer

[Andrea Corallo via Emacs development discussions.]

Eric Abrahamsen <eric@ericabrahamsen.net> writes:

> I forgot to say, I only put this check on one of the three
> `display-warning' call-sites in this file, because the others looked
> like fairly specific situations that the user should be bothered about.
> If they should all have it, I can do that, too.
>
> Eric

I agree with you that's the only place I'd gate `display-warning' in
comp.el for now.

  Andrea

Re: native-comp *Warnings* buffer

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 16 May 2021 23:23:34 -0400
> Cc: monnier@iro.umontreal.ca, emacs-devel@gnu.org
> 
> If you were going to have a compilation of foo.el based on some
> explicit request, and therefore see its warnings then,
> anything that compiles it by anticipation
> and does not show you its warnings
> could cause that explicit request NOT to compile it
> (because it was compiled recently), and therefore you
> would never see its warnings.

I don't think I understand the scenario you described.  Could you
perhaps describe it in simpler terms, like

  . user does A
  . Emacs does X and shows Y
  . user does B
  . emacs shows Z

etc.?

I'm asking because I'd like to figure out what we currently do in this
situation, and how this discussion could affect that.

Thanks.