unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* native-comp-async-report-warnings-errors default value
@ 2021-10-14 11:23 Robert Pluim
  2021-10-14 11:30 ` Eli Zaretskii
  0 siblings, 1 reply; 63+ messages in thread
From: Robert Pluim @ 2021-10-14 11:23 UTC (permalink / raw)
  To: emacs-devel

I just built emacs-28 --with-native-compilation, started up Emacs, and
then watched aghast as it spewed hundreds of warnings whilst native
compiling, preventing me from getting anything useful done for quite
some time.

Can we default this to `silent'?

Robert
-- 



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-10-14 11:23 native-comp-async-report-warnings-errors default value Robert Pluim
@ 2021-10-14 11:30 ` Eli Zaretskii
  2021-10-14 11:43   ` Robert Pluim
  0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2021-10-14 11:30 UTC (permalink / raw)
  To: Robert Pluim; +Cc: emacs-devel

> From: Robert Pluim <rpluim@gmail.com>
> Date: Thu, 14 Oct 2021 13:23:44 +0200
> 
> I just built emacs-28 --with-native-compilation, started up Emacs, and
> then watched aghast as it spewed hundreds of warnings whilst native
> compiling, preventing me from getting anything useful done for quite
> some time.
> 
> Can we default this to `silent'?

No, not yet: too many problems that trigger those warnings need to be
fixed rather than swept under the carpet of silence.  But you can do
it in your customizations if you don't want to be bothered.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-10-14 11:30 ` Eli Zaretskii
@ 2021-10-14 11:43   ` Robert Pluim
  2021-10-14 11:52     ` Eli Zaretskii
                       ` (2 more replies)
  0 siblings, 3 replies; 63+ messages in thread
From: Robert Pluim @ 2021-10-14 11:43 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

>>>>> On Thu, 14 Oct 2021 14:30:45 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Date: Thu, 14 Oct 2021 13:23:44 +0200
    >> 
    >> I just built emacs-28 --with-native-compilation, started up Emacs, and
    >> then watched aghast as it spewed hundreds of warnings whilst native
    >> compiling, preventing me from getting anything useful done for quite
    >> some time.
    >> 
    >> Can we default this to `silent'?

    Eli> No, not yet: too many problems that trigger those warnings need to be
    Eli> fixed rather than swept under the carpet of silence.  But you can do
    Eli> it in your customizations if you don't want to be bothered.

As long as we do it just before we release emacs-28, I guess thatʼs
OK.

Robert
-- 



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-10-14 11:43   ` Robert Pluim
@ 2021-10-14 11:52     ` Eli Zaretskii
  2021-10-14 14:48       ` Robert Pluim
  2021-10-14 12:07     ` Stefan Kangas
  2021-12-02 17:03     ` Stefan Kangas
  2 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2021-10-14 11:52 UTC (permalink / raw)
  To: Robert Pluim; +Cc: emacs-devel

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 14 Oct 2021 13:43:32 +0200
> 
> >>>>> On Thu, 14 Oct 2021 14:30:45 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim@gmail.com>
>     >> Date: Thu, 14 Oct 2021 13:23:44 +0200
>     >> 
>     >> I just built emacs-28 --with-native-compilation, started up Emacs, and
>     >> then watched aghast as it spewed hundreds of warnings whilst native
>     >> compiling, preventing me from getting anything useful done for quite
>     >> some time.
>     >> 
>     >> Can we default this to `silent'?
> 
>     Eli> No, not yet: too many problems that trigger those warnings need to be
>     Eli> fixed rather than swept under the carpet of silence.  But you can do
>     Eli> it in your customizations if you don't want to be bothered.
> 
> As long as we do it just before we release emacs-28, I guess thatʼs
> OK.

Please report the warnings, if they are in core files.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-10-14 11:43   ` Robert Pluim
  2021-10-14 11:52     ` Eli Zaretskii
@ 2021-10-14 12:07     ` Stefan Kangas
  2021-10-14 12:12       ` Eli Zaretskii
  2021-12-02 17:03     ` Stefan Kangas
  2 siblings, 1 reply; 63+ messages in thread
From: Stefan Kangas @ 2021-10-14 12:07 UTC (permalink / raw)
  To: Robert Pluim, Eli Zaretskii; +Cc: emacs-devel

Robert Pluim <rpluim@gmail.com> writes:

> As long as we do it just before we release emacs-28, I guess thatʼs
> OK.

Indeed.  These warnings make Emacs rather unusable for a while after
start if you have many packages.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-10-14 12:07     ` Stefan Kangas
@ 2021-10-14 12:12       ` Eli Zaretskii
  0 siblings, 0 replies; 63+ messages in thread
From: Eli Zaretskii @ 2021-10-14 12:12 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: rpluim, emacs-devel

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 14 Oct 2021 05:07:42 -0700
> Cc: emacs-devel@gnu.org
> 
> Robert Pluim <rpluim@gmail.com> writes:
> 
> > As long as we do it just before we release emacs-28, I guess thatʼs
> > OK.
> 
> Indeed.  These warnings make Emacs rather unusable for a while after
> start if you have many packages.

You can facilitate the solution by reporting those warnings more
eagerly.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-10-14 11:52     ` Eli Zaretskii
@ 2021-10-14 14:48       ` Robert Pluim
  2021-10-14 15:57         ` Eli Zaretskii
  0 siblings, 1 reply; 63+ messages in thread
From: Robert Pluim @ 2021-10-14 14:48 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

>>>>> On Thu, 14 Oct 2021 14:52:32 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> As long as we do it just before we release emacs-28, I guess thatʼs
    >> OK.

    Eli> Please report the warnings, if they are in core files.

Theyʼre all in packages, so far. Although one of those is org, so
perhaps I should switch back to the in-tree version for a while.

Robert
-- 



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-10-14 14:48       ` Robert Pluim
@ 2021-10-14 15:57         ` Eli Zaretskii
  2021-10-14 16:42           ` Lars Ingebrigtsen
  2021-10-15  8:51           ` Robert Pluim
  0 siblings, 2 replies; 63+ messages in thread
From: Eli Zaretskii @ 2021-10-14 15:57 UTC (permalink / raw)
  To: Robert Pluim; +Cc: emacs-devel

> From: Robert Pluim <rpluim@gmail.com>
> Cc: emacs-devel@gnu.org
> Date: Thu, 14 Oct 2021 16:48:31 +0200
> 
> >>>>> On Thu, 14 Oct 2021 14:52:32 +0300, Eli Zaretskii <eliz@gnu.org> said:
> 
>     >> As long as we do it just before we release emacs-28, I guess thatʼs
>     >> OK.
> 
>     Eli> Please report the warnings, if they are in core files.
> 
> Theyʼre all in packages, so far.

Those should be reported to the corresponding developers.

> Although one of those is org, so perhaps I should switch back to the
> in-tree version for a while.

Is your current version newer than the one on emacs-28?  If so, I
think the warnings should be reported to Org developers.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-10-14 15:57         ` Eli Zaretskii
@ 2021-10-14 16:42           ` Lars Ingebrigtsen
  2021-10-14 16:47             ` Eli Zaretskii
  2021-10-15  8:51           ` Robert Pluim
  1 sibling, 1 reply; 63+ messages in thread
From: Lars Ingebrigtsen @ 2021-10-14 16:42 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Robert Pluim, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> Theyʼre all in packages, so far.
>
> Those should be reported to the corresponding developers.

Having compilation warnings in packages is very normal (and is because
the packages target a wide range of Emacs versions).  I don't think it's
a productive use of our time to report them (even if some of them can be
suppressed).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-10-14 16:42           ` Lars Ingebrigtsen
@ 2021-10-14 16:47             ` Eli Zaretskii
  0 siblings, 0 replies; 63+ messages in thread
From: Eli Zaretskii @ 2021-10-14 16:47 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: rpluim, emacs-devel

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Robert Pluim <rpluim@gmail.com>,  emacs-devel@gnu.org
> Date: Thu, 14 Oct 2021 18:42:38 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> Theyʼre all in packages, so far.
> >
> > Those should be reported to the corresponding developers.
> 
> Having compilation warnings in packages is very normal (and is because
> the packages target a wide range of Emacs versions).  I don't think it's
> a productive use of our time to report them (even if some of them can be
> suppressed).

I won't insist.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-10-14 15:57         ` Eli Zaretskii
  2021-10-14 16:42           ` Lars Ingebrigtsen
@ 2021-10-15  8:51           ` Robert Pluim
  1 sibling, 0 replies; 63+ messages in thread
From: Robert Pluim @ 2021-10-15  8:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: emacs-devel

>>>>> On Thu, 14 Oct 2021 18:57:25 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: emacs-devel@gnu.org
    >> Date: Thu, 14 Oct 2021 16:48:31 +0200
    >> 
    >> >>>>> On Thu, 14 Oct 2021 14:52:32 +0300, Eli Zaretskii <eliz@gnu.org> said:
    >> 
    >> >> As long as we do it just before we release emacs-28, I guess thatʼs
    >> >> OK.
    >> 
    Eli> Please report the warnings, if they are in core files.
    >> 
    >> Theyʼre all in packages, so far.

    Eli> Those should be reported to the corresponding developers.

    >> Although one of those is org, so perhaps I should switch back to the
    >> in-tree version for a while.

    Eli> Is your current version newer than the one on emacs-28?  If so, I
    Eli> think the warnings should be reported to Org developers.

No, itʼs older, which is why Iʼll switch to the in-repo one.

Robert
-- 



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-10-14 11:43   ` Robert Pluim
  2021-10-14 11:52     ` Eli Zaretskii
  2021-10-14 12:07     ` Stefan Kangas
@ 2021-12-02 17:03     ` Stefan Kangas
  2021-12-02 17:10       ` Lars Ingebrigtsen
                         ` (2 more replies)
  2 siblings, 3 replies; 63+ messages in thread
From: Stefan Kangas @ 2021-12-02 17:03 UTC (permalink / raw)
  To: Robert Pluim, Eli Zaretskii; +Cc: emacs-devel

Robert Pluim <rpluim@gmail.com> writes:

>     Eli> No, not yet: too many problems that trigger those warnings need to be
>     Eli> fixed rather than swept under the carpet of silence.  But you can do
>     Eli> it in your customizations if you don't want to be bothered.
>
> As long as we do it just before we release emacs-28, I guess thatʼs
> OK.

Is it time to make this change on emacs-28 now?  Do we have any real
problems left to fix in Emacs itself?

If it is important to keep, how about a default like

    (= emacs-minor-version 0)

so that users at least don't have to see this in the released version?

Note that this gives spurious warnings for general init file stuff like
setting undefined variables:

    Warning (comp): init-general.el:45:7: Warning: assignment to free
variable ‘display-time-24hr-format’
    Warning (comp): init-general.el:46:7: Warning: assignment to free
variable ‘bookmark-save-flag’
    Warning (comp): init-general.el:48:7: Warning: assignment to free
variable ‘Man-width’

(I have tons of these here.)



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-02 17:03     ` Stefan Kangas
@ 2021-12-02 17:10       ` Lars Ingebrigtsen
  2021-12-02 17:14         ` Andrea Corallo
  2021-12-02 18:23       ` Eli Zaretskii
  2021-12-02 21:14       ` T.V Raman
  2 siblings, 1 reply; 63+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-02 17:10 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Robert Pluim, Eli Zaretskii, emacs-devel

Stefan Kangas <stefankangas@gmail.com> writes:

> Robert Pluim <rpluim@gmail.com> writes:
>
>>     Eli> No, not yet: too many problems that trigger those warnings need to be
>>     Eli> fixed rather than swept under the carpet of silence.  But you can do
>>     Eli> it in your customizations if you don't want to be bothered.
>>
>> As long as we do it just before we release emacs-28, I guess thatʼs
>> OK.
>
> Is it time to make this change on emacs-28 now?  Do we have any real
> problems left to fix in Emacs itself?
>
> If it is important to keep, how about a default like
>
>     (= emacs-minor-version 0)
>
> so that users at least don't have to see this in the released version?

I think it would make sense to disable this in the pretests, too, since
we'll be seeing lots of people trying those out, and they'll be getting
all these warnings (that won't be doing them any good).

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-02 17:10       ` Lars Ingebrigtsen
@ 2021-12-02 17:14         ` Andrea Corallo
  2021-12-02 21:15           ` T.V Raman
  0 siblings, 1 reply; 63+ messages in thread
From: Andrea Corallo @ 2021-12-02 17:14 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Robert Pluim, Eli Zaretskii, Stefan Kangas, emacs-devel

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Stefan Kangas <stefankangas@gmail.com> writes:
>
>> Robert Pluim <rpluim@gmail.com> writes:
>>
>>>     Eli> No, not yet: too many problems that trigger those warnings need to be
>>>     Eli> fixed rather than swept under the carpet of silence.  But you can do
>>>     Eli> it in your customizations if you don't want to be bothered.
>>>
>>> As long as we do it just before we release emacs-28, I guess thatʼs
>>> OK.
>>
>> Is it time to make this change on emacs-28 now?  Do we have any real
>> problems left to fix in Emacs itself?
>>
>> If it is important to keep, how about a default like
>>
>>     (= emacs-minor-version 0)
>>
>> so that users at least don't have to see this in the released version?
>
> I think it would make sense to disable this in the pretests, too, since
> we'll be seeing lots of people trying those out, and they'll be getting
> all these warnings (that won't be doing them any good).

+1



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-02 17:03     ` Stefan Kangas
  2021-12-02 17:10       ` Lars Ingebrigtsen
@ 2021-12-02 18:23       ` Eli Zaretskii
  2021-12-02 19:27         ` Stefan Kangas
  2021-12-02 21:14       ` T.V Raman
  2 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2021-12-02 18:23 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: rpluim, emacs-devel

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 2 Dec 2021 09:03:13 -0800
> Cc: emacs-devel@gnu.org
> 
> Is it time to make this change on emacs-28 now?  Do we have any real
> problems left to fix in Emacs itself?

The situations where you seem to bump into this have nothing to do
with Emacs sources, do they?

> Note that this gives spurious warnings for general init file stuff like
> setting undefined variables:
> 
>     Warning (comp): init-general.el:45:7: Warning: assignment to free
> variable ‘display-time-24hr-format’
>     Warning (comp): init-general.el:46:7: Warning: assignment to free
> variable ‘bookmark-save-flag’
>     Warning (comp): init-general.el:48:7: Warning: assignment to free
> variable ‘Man-width’

Why are you compiling your init files?

Anyway, if we want to disable warning when natively-compiling init
files, how about doing only that?  I'm running a natively-compiled
Emacs 28 for a couple of weeks now, and I have yet to see a single
warning like those above.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-02 18:23       ` Eli Zaretskii
@ 2021-12-02 19:27         ` Stefan Kangas
  2021-12-02 19:42           ` Eli Zaretskii
  0 siblings, 1 reply; 63+ messages in thread
From: Stefan Kangas @ 2021-12-02 19:27 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rpluim, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> The situations where you seem to bump into this have nothing to do
> with Emacs sources, do they?

AFAIR, I haven't seen a warning related to Emacs sources in there in a
long time.  I checked the *Warnings* buffer in my current session, and
none of what I have there is related to Emacs sources.

> Why are you compiling your init files?

In pre-historic times I learned that it speeds up start-up.  These days
it's more trouble than it's worth as I routinely leave Emacs running for
weeks on end.  I've been meaning to disable it, but didn't yet bother.

However, I often see this practice recommended in the community, as some
people seem to care deeply about shaving that extra 0.2 seconds (or
whatever it comes up to) off their startup time.

> Anyway, if we want to disable warning when natively-compiling init
> files, how about doing only that?  I'm running a natively-compiled
> Emacs 28 for a couple of weeks now, and I have yet to see a single
> warning like those above.

We should note that this will lead to (potentially a lot of) warnings
from third-party packages, many of which are rather slow to react to
compiler warnings.  Maybe this will light a fire under them though.

Also, can we tell what is an init file and what is a package?

How do we see this affecting the first pretest?  I am ready to release
the tarball I have now, but if we want to change anything here I can
recreate and reconfirm with the relevant change at the drop of a hat.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-02 19:27         ` Stefan Kangas
@ 2021-12-02 19:42           ` Eli Zaretskii
  2021-12-06 20:11             ` Stefan Kangas
  0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2021-12-02 19:42 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: rpluim, emacs-devel

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Thu, 2 Dec 2021 11:27:45 -0800
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> Also, can we tell what is an init file and what is a package?

Emacs knows when it loads the init file.  We could disable warnings
during that load, perhaps.

> How do we see this affecting the first pretest?  I am ready to release
> the tarball I have now, but if we want to change anything here I can
> recreate and reconfirm with the relevant change at the drop of a hat.

That's exactly why I don't want to make any significant changes at
this time.  We have waited long enough for the pretest, so let's
proceed without further ado.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-02 17:03     ` Stefan Kangas
  2021-12-02 17:10       ` Lars Ingebrigtsen
  2021-12-02 18:23       ` Eli Zaretskii
@ 2021-12-02 21:14       ` T.V Raman
  2021-12-03  6:50         ` Eli Zaretskii
  2 siblings, 1 reply; 63+ messages in thread
From: T.V Raman @ 2021-12-02 21:14 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Robert Pluim, Eli Zaretskii, emacs-devel

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

Stefan Kangas <stefankangas@gmail.com> writes:


This warning also triggers for 3rd party packages that have complex
build dependencies.
> Robert Pluim <rpluim@gmail.com> writes:
>
>>     Eli> No, not yet: too many problems that trigger those warnings need to be
>>     Eli> fixed rather than swept under the carpet of silence.  But you can do
>>     Eli> it in your customizations if you don't want to be bothered.
>>
>> As long as we do it just before we release emacs-28, I guess that0¶3s
>> OK.
>
> Is it time to make this change on emacs-28 now?  Do we have any real
> problems left to fix in Emacs itself?
>
> If it is important to keep, how about a default like
>
>     (= emacs-minor-version 0)
>
> so that users at least don't have to see this in the released version?
>
> Note that this gives spurious warnings for general init file stuff like
> setting undefined variables:
>
>     Warning (comp): init-general.el:45:7: Warning: assignment to free
> variable ¡®display-time-24hr-format¡¯
>     Warning (comp): init-general.el:46:7: Warning: assignment to free
> variable ¡®bookmark-save-flag¡¯
>     Warning (comp): init-general.el:48:7: Warning: assignment to free
> variable ¡®Man-width¡¯
>
> (I have tons of these here.)
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-02 17:14         ` Andrea Corallo
@ 2021-12-02 21:15           ` T.V Raman
  0 siblings, 0 replies; 63+ messages in thread
From: T.V Raman @ 2021-12-02 21:15 UTC (permalink / raw)
  To: Andrea Corallo
  Cc: Lars Ingebrigtsen, Robert Pluim, Eli Zaretskii, Stefan Kangas,
	emacs-devel

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

Andrea Corallo <akrl@sdf.org> writes:


They're mostly spurious except when they are not, and in those cases,
the packages generating them will likely misbehave.
> Lars Ingebrigtsen <larsi@gnus.org> writes:
>
>> Stefan Kangas <stefankangas@gmail.com> writes:
>>
>>> Robert Pluim <rpluim@gmail.com> writes:
>>>
>>>>     Eli> No, not yet: too many problems that trigger those warnings need to be
>>>>     Eli> fixed rather than swept under the carpet of silence.  But you can do
>>>>     Eli> it in your customizations if you don't want to be bothered.
>>>>
>>>> As long as we do it just before we release emacs-28, I guess that0¶3s
>>>> OK.
>>>
>>> Is it time to make this change on emacs-28 now?  Do we have any real
>>> problems left to fix in Emacs itself?
>>>
>>> If it is important to keep, how about a default like
>>>
>>>     (= emacs-minor-version 0)
>>>
>>> so that users at least don't have to see this in the released version?
>>
>> I think it would make sense to disable this in the pretests, too, since
>> we'll be seeing lots of people trying those out, and they'll be getting
>> all these warnings (that won't be doing them any good).
>
> +1
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-02 21:14       ` T.V Raman
@ 2021-12-03  6:50         ` Eli Zaretskii
  0 siblings, 0 replies; 63+ messages in thread
From: Eli Zaretskii @ 2021-12-03  6:50 UTC (permalink / raw)
  To: T.V Raman; +Cc: rpluim, stefankangas, emacs-devel

> From: "T.V Raman" <raman@google.com>
> Cc: Robert Pluim <rpluim@gmail.com>,  Eli Zaretskii <eliz@gnu.org>,
>   emacs-devel@gnu.org
> Date: Thu, 02 Dec 2021 13:14:52 -0800
> 
> This warning also triggers for 3rd party packages that have complex
> build dependencies.

The variable is there, available for local customizations if some
unusual need arises.  This discussion is about the default value.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-02 19:42           ` Eli Zaretskii
@ 2021-12-06 20:11             ` Stefan Kangas
  2021-12-06 20:26               ` Eli Zaretskii
  0 siblings, 1 reply; 63+ messages in thread
From: Stefan Kangas @ 2021-12-06 20:11 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rpluim, emacs-devel

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

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Stefan Kangas <stefankangas@gmail.com>
>> Date: Thu, 2 Dec 2021 11:27:45 -0800
>> Cc: rpluim@gmail.com, emacs-devel@gnu.org
>>
>> Also, can we tell what is an init file and what is a package?
>
> Emacs knows when it loads the init file.  We could disable warnings
> during that load, perhaps.

That works until you require some package from there, I think.  In any
case, that would need someone to step up to write that code, and it
sounds a whole deal more complicated than just flipping
native-comp-async-report-warnings-errors to nil.

And even then, it won't fix the issue completely.

Please see the attached file with just the warnings I get from starting
Emacs with current master and my init file.  I disabled compiling my
init files, so this is just what I get from third-party packages.  Not
all of them though, as some of them aren't yet loaded -- I will have fun
with a *Warning* buffer popping up in the middle of doing something else
every now and then for the next week or more.

Some of these packages haven't seen updates in years, so I have little
confidence that these warnings will suddenly be fixed in time for Emacs
28.1, even if I did spend a day or two going through and reporting bugs
for all of them.  In some cases, I already have open pull requests that
have seen no action or reply in over a year (!).  And then remains, of
course, the many thousands packages that neither I or anyone else on
this list use.

I am all for showing warnings visibly, but this is an overly intrusive
way to do it, as is evidenced by the many complaints we've seen about it
so far.  In conclusion, I insist that we would do well to flip the
default of native-comp-async-report-warnings-errors to `silent' or nil
for the second Emacs 28 pretest.

[-- Attachment #2: warnings.txt --]
[-- Type: text/plain, Size: 26228 bytes --]

Warning (comp): debian-ispell.el:229:17: Warning: assignment to free variable ‘really-hunspell’ Disable showing Disable logging
Warning (comp): debian-ispell.el:228:28: Warning: reference to free variable ‘really-hunspell’ Disable showing Disable logging
Warning (comp): debian-ispell.el:386:16: Warning: reference to free variable ‘ispell-program-name’ Disable showing Disable logging
Warning (comp): debian-ispell.el:392:16: Warning: reference to free variable ‘ispell-local-dictionary’ Disable showing Disable logging
Warning (comp): debian-ispell.el:393:16: Warning: reference to free variable ‘ispell-dictionary’ Disable showing Disable logging
Warning (comp): debian-ispell.el:403:24: Warning: assignment to free variable ‘ispell-base-dicts-override-alist’ Disable showing Disable logging
Warning (comp): debian-ispell.el:403:20: Warning: reference to free variable ‘ispell-base-dicts-override-alist’ Disable showing Disable logging
Warning (comp): debian-ispell.el:450:10: Warning: reference to free variable ‘ispell-dictionary’ Disable showing Disable logging
Warning (comp): debian-ispell.el:450:10: Warning: reference to free variable ‘ispell-program-name’ Disable showing Disable logging
Warning (comp): debian-ispell.el:469:38: Warning: reference to free variable ‘debian-emacs-flavor’ Disable showing Disable logging
Warning (comp): debian-ispell.el:493:15: Warning: the function ‘ispell-set-spellchecker-params’ is not known to be defined. Disable showing Disable logging
Warning (comp): bind-key.el:134:20: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): dash.el:615:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:628:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:645:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1059:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1219:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1272:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1320:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1335:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1341:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:1523:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:2613:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:2632:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): dash.el:3318:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): s.el:402:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): s.el:407:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ag.el:171:1: Warning: defvar `ag/file-column-pattern-nogroup' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ag.el:179:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ag.el:202:13: Warning: (lambda nil \.\.\.) quoted with ' rather than with #' Disable showing Disable logging
Warning (comp): centered-window.el:75:1: Warning: custom-declare-variable `cwm-incremental-padding' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): centered-window.el:218:69: Warning: reference to free variable ‘centered-window-mode’ Disable showing Disable logging
Warning (comp): centered-window.el:275:7: Warning: reference to free variable ‘centered-window-mode’ Disable showing Disable logging
Warning (comp): discover.el:414:31: Warning: defcustom for ‘global-discover-mode’ fails to specify containing group Disable showing Disable logging
Warning (comp): discover.el:414:31: Warning: defcustom for ‘global-discover-mode’ fails to specify containing group Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:252:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:273:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:352:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:381:23: Warning: reference to free variable ‘mc/cmds-to-run-for-all’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:381:23: Warning: assignment to free variable ‘mc/cmds-to-run-for-all’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:382:21: Warning: reference to free variable ‘mc/cmds-to-run-once’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:382:21: Warning: assignment to free variable ‘mc/cmds-to-run-once’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:468:56: Warning: reference to free variable ‘mc--default-cmds-to-run-once’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:469:56: Warning: reference to free variable ‘mc/cmds-to-run-once’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:471:55: Warning: reference to free variable ‘mc--default-cmds-to-run-for-all’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:472:55: Warning: reference to free variable ‘mc/cmds-to-run-for-all’ Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:566:1: Warning: defcustom for ‘mc/mode-line’ fails to specify type Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:566:1: Warning: defcustom for ‘mc/mode-line’ fails to specify type Disable showing Disable logging
Warning (comp): multiple-cursors-core.el:577:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): mc-cycle-cursors.el:95:22: Warning: reference to free variable ‘mc/cycle’ Disable showing Disable logging
Warning (comp): mc-mark-more.el:212:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:229:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:246:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:265:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:276:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:326:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:332:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:473:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:493:4: Warning: ‘set-temporary-overlay-map’ is an obsolete function (as of 24.4); use ‘set-transient-map’ instead. Disable showing Disable logging
Warning (comp): mc-mark-more.el:495:1: Warning: defvar `mc/mark-more-like-this-extended-direction' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): mc-mark-more.el:642:14: Warning: looking-back called with 1 argument, but requires 2-3 Disable showing Disable logging
Warning (comp): mc-mark-more.el:694:27: Warning: the function ‘sgml-skip-tag-forward’ is not known to be defined. Disable showing Disable logging
Warning (comp): mc-mark-more.el:643:8: Warning: the function ‘sgml-get-context’ is not known to be defined. Disable showing Disable logging
Warning (comp): mc-hide-unmatched-lines-mode.el:59:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): iedit-lib.el:138:1: Warning: defvar `iedit-lib-skip-invisible-count' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): iedit-lib.el:1144:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): iedit.el:173:1: Warning: defvar `iedit-default-occurrence-local' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ioccur.el:378:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ioccur.el:400:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ioccur.el:886:33: Warning: ‘tooltip-use-echo-area’ is an obsolete variable (as of 24.1); disable Tooltip mode instead Disable showing Disable logging
Warning (comp): ioccur.el:1103:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): rectangular-region-mode.el:52:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): rectangular-region-mode.el:115:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): openwith.el:97:14: Warning: reference to free variable ‘openwith-mode’ Disable showing Disable logging
Warning (comp): openwith.el:117:18: Warning: the function ‘recentf-add-file’ is not known to be defined. Disable showing Disable logging
Warning (comp): openwith.el:93:4: Warning: the function ‘w32-shell-execute’ is not known to be defined. Disable showing Disable logging
Warning (comp): undo-tree.el:2352:16: Warning: ‘undo-elt-crosses-region’ is an obsolete function (as of 25.1). Disable showing Disable logging
Warning (comp): undo-tree.el:2561:16: Warning: ‘undo-elt-crosses-region’ is an obsolete function (as of 25.1). Disable showing Disable logging
Warning (comp): undo-tree.el:2755:5: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): undo-tree.el:3140:14: Warning: ‘registerv-make’ is an obsolete function (as of 27.1); Use your own type with methods on register-val-(insert|describe|jump-to) Disable showing Disable logging
Warning (comp): hydra.el:103:1: Warning: defvar `hydra-amaranth-warn-message' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): elfeed-org.el:173:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): elfeed-org.el:186:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): elfeed-org.el:155:10: Warning: the function ‘org-element-put-property’ is not known to be defined. Disable showing Disable logging
Warning (comp): elfeed-org.el:116:34: Warning: the function ‘org-element-property’ is not known to be defined. Disable showing Disable logging
Warning (comp): elfeed-org.el:113:8: Warning: the function ‘org-element-parse-buffer’ is not known to be defined. Disable showing Disable logging
Warning (comp): elfeed-org.el:112:4: Warning: the function ‘org-element-map’ is not known to be defined. Disable showing Disable logging
Warning (comp): counsel.el:3021:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): counsel.el:3075:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): counsel.el:5573:26: Warning: reference to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5576:38: Warning: reference to free variable ‘kmacro-initial-counter-value’ Disable showing Disable logging
Warning (comp): counsel.el:5576:67: Warning: reference to free variable ‘kmacro-counter’ Disable showing Disable logging
Warning (comp): counsel.el:5600:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): counsel.el:5618:8: Warning: reference to free variable ‘kmacro-counter-value-start’ Disable showing Disable logging
Warning (comp): counsel.el:5619:8: Warning: reference to free variable ‘kmacro-counter-format-start’ Disable showing Disable logging
Warning (comp): counsel.el:5620:5: Warning: reference to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5625:30: Warning: Unused lexical variable `kmacro-counter-format-start' Disable showing Disable logging
Warning (comp): counsel.el:5638:23: Warning: reference to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5644:44: Warning: assignment to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5663:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): counsel.el:5681:31: Warning: reference to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5701:58: Warning: reference to free variable ‘kmacro-counter’ Disable showing Disable logging
Warning (comp): counsel.el:5712:31: Warning: reference to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5712:31: Warning: assignment to free variable ‘kmacro-ring’ Disable showing Disable logging
Warning (comp): counsel.el:5740:16: Warning: Unused lexical variable `kmacro-initial-counter-value' Disable showing Disable logging
Warning (comp): counsel.el:5740:31: Warning: Unused lexical variable `kmacro-counter-format-start' Disable showing Disable logging
Warning (comp): counsel.el:5682:10: Warning: the function ‘kmacro-cycle-ring-previous’ is not known to be defined. Disable showing Disable logging
Warning (comp): counsel.el:5668:6: Warning: the function ‘kmacro-set-format’ is not known to be defined. Disable showing Disable logging
Warning (comp): counsel.el:5661:6: Warning: the function ‘kmacro-set-counter’ is not known to be defined. Disable showing Disable logging
Warning (comp): counsel.el:5449:28: Warning: the function ‘list-colors-duplicates’ is not known to be defined. Disable showing Disable logging
Warning (comp): notmuch-draft.el:38:1: Warning: custom-declare-variable `notmuch-draft-tags' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-message.el:53:1: Warning: defconst `notmuch-message-queued-tag-changes' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-show.el:2318:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-show.el:2340:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-show.el:2351:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-show.el:2367:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-hello.el:122:1: Warning: custom-declare-variable `notmuch-saved-searches' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-hello.el:691:22: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-hello.el:869:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-tree.el:971:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): notmuch-tree.el:768:8: Warning: the function ‘notmuch-tree-from-search-thread’ is not known to be defined. Disable showing Disable logging
Warning (comp): notmuch-tree.el:767:10: Warning: the function ‘notmuch-search-next-thread’ is not known to be defined. Disable showing Disable logging
Warning (comp): notmuch-tree.el:766:12: Warning: the function ‘notmuch-search-previous-thread’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:109:43: Warning: reference to free variable ‘notmuch-search-query-string’ Disable showing Disable logging
Warning (comp): ol-notmuch.el:150:4: Warning: the function ‘notmuch-tree’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:135:42: Warning: the function ‘notmuch-tree-get-query’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:124:4: Warning: the function ‘notmuch-search’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:98:4: Warning: the function ‘notmuch-show’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:80:29: Warning: the function ‘notmuch-show-get-date’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:79:19: Warning: the function ‘notmuch-show-get-from’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:78:17: Warning: the function ‘notmuch-show-get-to’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:77:22: Warning: the function ‘notmuch-show-get-subject’ is not known to be defined. Disable showing Disable logging
Warning (comp): ol-notmuch.el:76:25: Warning: the function ‘notmuch-show-get-message-id’ is not known to be defined. Disable showing Disable logging
Warning (comp): org-bullets.el:111:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): org-download.el:558:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): org-download.el:526:22: Warning: the function ‘url-handler-file-remote-p’ is not known to be defined. Disable showing Disable logging
Warning (comp): company.el:785:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): company.el:1977:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): org-journal.el:430:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): org-journal.el:505:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): org-journal.el:571:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): org-journal.el:722:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): org-journal.el:1048:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): org-journal.el:1517:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:1224:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2058:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2066:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2075:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2083:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2089:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2100:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2198:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2225:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2253:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2449:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2571:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2586:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2639:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2691:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:2735:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:3397:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:3412:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:3518:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:3547:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:3558:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:4466:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): projectile.el:4965:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:1458:1: Warning: custom-declare-variable `sp-highlight-wrap-tag-overlay' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:2724:42: Warning: value returned from (< (sp--get-overlay-length nil) (sp--get-overlay-length nil)) is unused Disable showing Disable logging
Warning (comp): smartparens.el:2724:42: Warning: value returned from (< (sp--get-overlay-length nil) (sp--get-overlay-length nil)) is unused Disable showing Disable logging
Warning (comp): smartparens.el:2724:42: Warning: value returned from (< (sp--get-overlay-length nil) (sp--get-overlay-length nil)) is unused Disable showing Disable logging
Warning (comp): smartparens.el:2905:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:2911:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:5520:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:7186:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:8215:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:8714:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): smartparens.el:9397:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): ws-butler.el:153:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): aggressive-indent.el:503:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): aggressive-indent.el:504:16: Warning: reference to free variable ‘global-aggressive-indent-mode’ Disable showing Disable logging
Warning (comp): stream.el:316:15: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): stream-x.el:103:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): el-search.el:996:15: Warning: elisp--highlight-function-argument called with 4 arguments, but accepts only 3 Disable showing Disable logging
Warning (comp): el-search.el:2569:26: Warning: global/dynamic var ‘type’ lacks a prefix Disable showing Disable logging
Warning (comp): nameless.el:286:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): macrostep.el:291:1: Warning: defvar `macrostep-outer-environment' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): macrostep.el:363:1: Warning: custom-declare-variable `macrostep-expand-compiler-macros' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): macrostep.el:503:7: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): loop.el:105:11: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): loop.el:117:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): suggest.el:434:10: Warning: ‘format-proper-list-p’ is an obsolete function (as of 27.1); use ‘proper-list-p’ instead. Disable showing Disable logging
Warning (comp): winum.el:241:3: Warning: Use keywords rather than deprecated positional arguments to `define-minor-mode' Disable showing Disable logging
Warning (comp): yasnippet.el:477:1: Warning: defvar `yas-after-exit-snippet-hook' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): yasnippet.el:559:1: Warning: custom-declare-variable `yas-keymap-disable-hook' docstring wider than 80 characters Disable showing Disable logging
Warning (comp): yasnippet.el:1812:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): yasnippet.el:2984:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): yasnippet.el:4737:8: Warning: docstring wider than 80 characters Disable showing Disable logging
Warning (comp): .yas-setup.el:31:8: Warning: docstring wider than 80 characters Disable showing Disable logging

^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-06 20:11             ` Stefan Kangas
@ 2021-12-06 20:26               ` Eli Zaretskii
  2021-12-07  7:51                 ` Lars Ingebrigtsen
  2021-12-17 18:14                 ` Stefan Kangas
  0 siblings, 2 replies; 63+ messages in thread
From: Eli Zaretskii @ 2021-12-06 20:26 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: rpluim, emacs-devel

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Mon, 6 Dec 2021 21:11:21 +0100
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> > Emacs knows when it loads the init file.  We could disable warnings
> > during that load, perhaps.
> 
> That works until you require some package from there, I think.  In any
> case, that would need someone to step up to write that code, and it
> sounds a whole deal more complicated than just flipping
> native-comp-async-report-warnings-errors to nil.

Then flip it.  For yourself.  Why decide for all the others?

I'd rather sustain a barrage of annoyed people who think these
warnings are gratuitous than explain to someone why Emacs decided to
shut up these warnings by default and thus prevented him/her from
seeing some warning which, if seen in time, could avoid a crash or
some other catastrophic result.

Native compilation is still in its diapers.  We learn about new
aspects and potential issues with it almost every day.  Sweeping
warnings under the carpet in this situation makes very little sense to
me.  It's our minimal safety net.

But if "by popular demand" and other pressure, you will decide to
disable the warnings nonetheless, I won't mount the barricades.  My
opinion about this is unchanged, but feel free to disregard it.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-06 20:26               ` Eli Zaretskii
@ 2021-12-07  7:51                 ` Lars Ingebrigtsen
  2021-12-07  9:37                   ` Andrea Corallo
  2021-12-07 14:15                   ` Eli Zaretskii
  2021-12-17 18:14                 ` Stefan Kangas
  1 sibling, 2 replies; 63+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-07  7:51 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rpluim, Stefan Kangas, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> I'd rather sustain a barrage of annoyed people who think these
> warnings are gratuitous than explain to someone why Emacs decided to
> shut up these warnings by default and thus prevented him/her from
> seeing some warning which, if seen in time, could avoid a crash or
> some other catastrophic result.

In my opinion, it's not something we should be showing to users.  It's
highly irregular that we do -- we didn't present users saying "emacs"
with all the compilation warnings from building Emacs in Emacs 27.2, but
that's (in effect) what we're doing now.

Compilation warnings are for developers, not users, so builds that are
geared towards users (as pretests are) should have this switched off.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-07  7:51                 ` Lars Ingebrigtsen
@ 2021-12-07  9:37                   ` Andrea Corallo
  2021-12-07  9:42                     ` Robert Pluim
  2021-12-07 13:24                     ` Stefan Monnier
  2021-12-07 14:15                   ` Eli Zaretskii
  1 sibling, 2 replies; 63+ messages in thread
From: Andrea Corallo @ 2021-12-07  9:37 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: Eli Zaretskii, emacs-devel, rpluim, Stefan Kangas

Lars Ingebrigtsen <larsi@gnus.org> writes:

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> I'd rather sustain a barrage of annoyed people who think these
>> warnings are gratuitous than explain to someone why Emacs decided to
>> shut up these warnings by default and thus prevented him/her from
>> seeing some warning which, if seen in time, could avoid a crash or
>> some other catastrophic result.
>
> In my opinion, it's not something we should be showing to users.  It's
> highly irregular that we do -- we didn't present users saying "emacs"
> with all the compilation warnings from building Emacs in Emacs 27.2, but
> that's (in effect) what we're doing now.
>
> Compilation warnings are for developers, not users, so builds that are
> geared towards users (as pretests are) should have this switched off.

What is the problem with changing it after pretest is done?

In the Emacs world by definition there's no clear distinction between
users and developers, postponing the switch we maximize the probability
that some user/developer fix some broken code no?

  Andrea



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-07  9:37                   ` Andrea Corallo
@ 2021-12-07  9:42                     ` Robert Pluim
  2021-12-07  9:54                       ` Andrea Corallo
  2021-12-07 13:24                     ` Stefan Monnier
  1 sibling, 1 reply; 63+ messages in thread
From: Robert Pluim @ 2021-12-07  9:42 UTC (permalink / raw)
  To: Andrea Corallo
  Cc: Lars Ingebrigtsen, emacs-devel, Eli Zaretskii, Stefan Kangas

>>>>> On Tue, 07 Dec 2021 09:37:30 +0000, Andrea Corallo <akrl@sdf.org> said:

    Andrea> What is the problem with changing it after pretest is done?

    Andrea> In the Emacs world by definition there's no clear distinction between
    Andrea> users and developers, postponing the switch we maximize the probability
    Andrea> that some user/developer fix some broken code no?

Are there clear instructions somewhere mapping from the warnings to
the changes required in the 'broken code'? (I wouldnʼt call it 'broken'
if it works in current Emacs)

Robert
-- 



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-07  9:42                     ` Robert Pluim
@ 2021-12-07  9:54                       ` Andrea Corallo
  2021-12-07 12:38                         ` Robert Pluim
  0 siblings, 1 reply; 63+ messages in thread
From: Andrea Corallo @ 2021-12-07  9:54 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Lars Ingebrigtsen, emacs-devel, Eli Zaretskii, Stefan Kangas

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Tue, 07 Dec 2021 09:37:30 +0000, Andrea Corallo <akrl@sdf.org> said:
>
>     Andrea> What is the problem with changing it after pretest is done?
>
>     Andrea> In the Emacs world by definition there's no clear distinction between
>     Andrea> users and developers, postponing the switch we maximize the probability
>     Andrea> that some user/developer fix some broken code no?
>
> Are there clear instructions somewhere mapping from the warnings to
> the changes required in the 'broken code'? (I wouldnʼt call it 'broken'
> if it works in current Emacs)

The docstring of `native-comp-async-report-warnings-errors' itself
mention the tipical reason of this and its classical fix.  It might be
mentioned elsewhere tho, not sure.

  Andrea



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-07  9:54                       ` Andrea Corallo
@ 2021-12-07 12:38                         ` Robert Pluim
  2021-12-07 14:28                           ` Eli Zaretskii
  0 siblings, 1 reply; 63+ messages in thread
From: Robert Pluim @ 2021-12-07 12:38 UTC (permalink / raw)
  To: Andrea Corallo
  Cc: Lars Ingebrigtsen, emacs-devel, Eli Zaretskii, Stefan Kangas

>>>>> On Tue, 07 Dec 2021 09:54:12 +0000, Andrea Corallo <akrl@sdf.org> said:

    Andrea> Robert Pluim <rpluim@gmail.com> writes:
    >>>>>>> On Tue, 07 Dec 2021 09:37:30 +0000, Andrea Corallo <akrl@sdf.org> said:
    >> 
    Andrea> What is the problem with changing it after pretest is done?
    >> 
    Andrea> In the Emacs world by definition there's no clear distinction between
    Andrea> users and developers, postponing the switch we maximize the probability
    Andrea> that some user/developer fix some broken code no?
    >> 
    >> Are there clear instructions somewhere mapping from the warnings to
    >> the changes required in the 'broken code'? (I wouldnʼt call it 'broken'
    >> if it works in current Emacs)

    Andrea> The docstring of `native-comp-async-report-warnings-errors' itself
    Andrea> mention the tipical reason of this and its classical fix.  It might be
    Andrea> mentioned elsewhere tho, not sure.

Itʼs not in the elisp manual. I think the docstring of
`native-comp-async-report-warnings-errors' is also not discoverable
from the *Warnings* buffer, from what I remember.

Robert
-- 



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-07  9:37                   ` Andrea Corallo
  2021-12-07  9:42                     ` Robert Pluim
@ 2021-12-07 13:24                     ` Stefan Monnier
  2021-12-07 14:05                       ` Andrea Corallo
  1 sibling, 1 reply; 63+ messages in thread
From: Stefan Monnier @ 2021-12-07 13:24 UTC (permalink / raw)
  To: Andrea Corallo
  Cc: Lars Ingebrigtsen, Eli Zaretskii, emacs-devel, rpluim,
	Stefan Kangas

> What is the problem with changing it after pretest is done?

That's too late: changing something *after* the last pretest means
releasing code that has never been tested.  A pretest is basically
a release candidate.


        Stefan




^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-07 13:24                     ` Stefan Monnier
@ 2021-12-07 14:05                       ` Andrea Corallo
  2021-12-07 14:33                         ` Eli Zaretskii
  0 siblings, 1 reply; 63+ messages in thread
From: Andrea Corallo @ 2021-12-07 14:05 UTC (permalink / raw)
  To: Stefan Monnier
  Cc: Lars Ingebrigtsen, rpluim, Stefan Kangas, Eli Zaretskii,
	emacs-devel

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> What is the problem with changing it after pretest is done?
>
> That's too late: changing something *after* the last pretest means
> releasing code that has never been tested.  A pretest is basically
> a release candidate.

Okay, my understanding was this was our intention, I guess I've got it
wrong.

  Andrea



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-07  7:51                 ` Lars Ingebrigtsen
  2021-12-07  9:37                   ` Andrea Corallo
@ 2021-12-07 14:15                   ` Eli Zaretskii
  2021-12-07 20:20                     ` Lars Ingebrigtsen
  1 sibling, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2021-12-07 14:15 UTC (permalink / raw)
  To: Lars Ingebrigtsen; +Cc: rpluim, stefankangas, emacs-devel

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Kangas <stefankangas@gmail.com>,  rpluim@gmail.com,
>   emacs-devel@gnu.org
> Date: Tue, 07 Dec 2021 08:51:28 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I'd rather sustain a barrage of annoyed people who think these
> > warnings are gratuitous than explain to someone why Emacs decided to
> > shut up these warnings by default and thus prevented him/her from
> > seeing some warning which, if seen in time, could avoid a crash or
> > some other catastrophic result.
> 
> In my opinion, it's not something we should be showing to users.  It's
> highly irregular that we do -- we didn't present users saying "emacs"
> with all the compilation warnings from building Emacs in Emacs 27.2, but
> that's (in effect) what we're doing now.
> 
> Compilation warnings are for developers, not users, so builds that are
> geared towards users (as pretests are) should have this switched off.

If the user visits a Lisp file and clicks the Emacs Lisp->Byte Compile
item on the menu bar, we do pop up the compilation log buffer with the
warnings and errors, right?

And if the user installs or upgrades a package from ELPA, and the
package is byte-compiled, the messages from that are shown, right?

So it sounds like we already show these messages to users, and this is
just another such situation.  Once we decided to have JIT native
compilation (and IMO it wouldn't make sense to decide differently), we
should also agree to this side effect of compiling code in the
background.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-07 12:38                         ` Robert Pluim
@ 2021-12-07 14:28                           ` Eli Zaretskii
  2021-12-07 16:54                             ` Robert Pluim
  0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2021-12-07 14:28 UTC (permalink / raw)
  To: Robert Pluim; +Cc: larsi, emacs-devel, stefankangas, akrl

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>,  Eli Zaretskii <eliz@gnu.org>,
>   Stefan Kangas <stefankangas@gmail.com>,  emacs-devel@gnu.org
> Date: Tue, 07 Dec 2021 13:38:01 +0100
> 
> >>>>> On Tue, 07 Dec 2021 09:54:12 +0000, Andrea Corallo <akrl@sdf.org> said:
> 
>     Andrea> Robert Pluim <rpluim@gmail.com> writes:
>     >>>>>>> On Tue, 07 Dec 2021 09:37:30 +0000, Andrea Corallo <akrl@sdf.org> said:
>     >> 
>     Andrea> What is the problem with changing it after pretest is done?
>     >> 
>     Andrea> In the Emacs world by definition there's no clear distinction between
>     Andrea> users and developers, postponing the switch we maximize the probability
>     Andrea> that some user/developer fix some broken code no?
>     >> 
>     >> Are there clear instructions somewhere mapping from the warnings to
>     >> the changes required in the 'broken code'? (I wouldnʼt call it 'broken'
>     >> if it works in current Emacs)
> 
>     Andrea> The docstring of `native-comp-async-report-warnings-errors' itself
>     Andrea> mention the tipical reason of this and its classical fix.  It might be
>     Andrea> mentioned elsewhere tho, not sure.
> 
> Itʼs not in the elisp manual. I think the docstring of
> `native-comp-async-report-warnings-errors' is also not discoverable
> from the *Warnings* buffer, from what I remember.

We can always improve the documentation in this area.  Feel free to
propose a patch, or explain what needs to be improved there, so that
someone else could do it.

TIA



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-07 14:05                       ` Andrea Corallo
@ 2021-12-07 14:33                         ` Eli Zaretskii
  0 siblings, 0 replies; 63+ messages in thread
From: Eli Zaretskii @ 2021-12-07 14:33 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: larsi, rpluim, stefan, monnier, emacs-devel

> From: Andrea Corallo <akrl@sdf.org>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Eli Zaretskii <eliz@gnu.org>,
>         emacs-devel@gnu.org, rpluim@gmail.com,
>         Stefan Kangas
>  <stefan@marxist.se>
> Date: Tue, 07 Dec 2021 14:05:55 +0000
> 
> Stefan Monnier <monnier@iro.umontreal.ca> writes:
> 
> >> What is the problem with changing it after pretest is done?
> >
> > That's too late: changing something *after* the last pretest means
> > releasing code that has never been tested.  A pretest is basically
> > a release candidate.
> 
> Okay, my understanding was this was our intention

Almost: we talked about disabling it close to the release, but still
during the pretest.  That is still an option: we just had the first
pretest, and there will be definitely at least one more.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-07 14:28                           ` Eli Zaretskii
@ 2021-12-07 16:54                             ` Robert Pluim
  2021-12-07 17:16                               ` Eli Zaretskii
  0 siblings, 1 reply; 63+ messages in thread
From: Robert Pluim @ 2021-12-07 16:54 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, emacs-devel, stefankangas, akrl

>>>>> On Tue, 07 Dec 2021 16:28:22 +0200, Eli Zaretskii <eliz@gnu.org> said:
    >> Itʼs not in the elisp manual. I think the docstring of
    >> `native-comp-async-report-warnings-errors' is also not discoverable
    >> from the *Warnings* buffer, from what I remember.

    Eli> We can always improve the documentation in this area.  Feel free to
    Eli> propose a patch, or explain what needs to be improved there, so that
    Eli> someone else could do it.

Let the wordsmithing begin!

diff --git a/doc/lispref/compile.texi b/doc/lispref/compile.texi
index 523758c10f..a3557e6855 100644
--- a/doc/lispref/compile.texi
+++ b/doc/lispref/compile.texi
@@ -924,7 +924,11 @@ Native-Compilation Functions
 use while the compilation runs in the background.  This is the method
 used by Emacs to natively-compile any Lisp file or byte-compiled Lisp
 file that is loaded into Emacs, when no natively-compiled file for it
-is available.
+is available.  Note that because of this use of a subprocess, native
+compilation may produce warning and errors which byte-compilation does
+not, and lisp code may thus need to be modified to work correctly. See
+@code{native-comp-async-report-warnings-errors} in @xref{Native-Compilation
+Variables} for more details.
 
 @defun native-compile-async files &optional recursively load selector
 This function compiles the named @var{files} asynchronously.  The
@@ -1038,6 +1042,12 @@ Native-Compilation Variables
 @code{t} means display the resulting buffer.  To log warnings without
 popping up the @file{*Warnings*} buffer, set this variable to
 @code{silent}.
+
+  A common cause for asynchronous native-compilation to produce
+warnings is compiling a file that is missing some @code{require} of a
+necessary feature.  The feature may be loaded into the main emacs, but
+because native compilation always starts from a subprocess with a
+pristine environment, that may not be true for the subprocess.
 @end defopt
 
 @defopt native-comp-async-query-on-exit

diff --git a/doc/lispref/compile.texi b/doc/lispref/compile.texi
index 523758c10f..850cdff465 100644
--- a/doc/lispref/compile.texi
+++ b/doc/lispref/compile.texi
@@ -924,7 +924,10 @@ Native-Compilation Functions
 use while the compilation runs in the background.  This is the method
 used by Emacs to natively-compile any Lisp file or byte-compiled Lisp
 file that is loaded into Emacs, when no natively-compiled file for it
-is available.
+is available.  Note that because of this use of a subprocess, native
+compilation may produce warning and errors which byte-compilation does
+not, and lisp code may thus need to be modified to work correctly. See
+@code{native-comp-async-report-warnings-errors} for more details.
 
 @defun native-compile-async files &optional recursively load selector
 This function compiles the named @var{files} asynchronously.  The

Regarding discoverability, the
*Warnings* buffer has entries like this:

    Warning (comp): tex-site.el:168:31: Warning: the function
    ‘BibTeX-auto-store’ is not known to be defined. Disable showing
    Disable logging

I guess we could add a link to
`native-comp-async-report-warnings-errors' when the warning type == (comp)

Robert
-- 



^ permalink raw reply related	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-07 16:54                             ` Robert Pluim
@ 2021-12-07 17:16                               ` Eli Zaretskii
  2021-12-08  9:19                                 ` Robert Pluim
  0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2021-12-07 17:16 UTC (permalink / raw)
  To: Robert Pluim; +Cc: larsi, emacs-devel, stefankangas, akrl

> From: Robert Pluim <rpluim@gmail.com>
> Cc: akrl@sdf.org,  larsi@gnus.org,  stefankangas@gmail.com,
>   emacs-devel@gnu.org
> Date: Tue, 07 Dec 2021 17:54:49 +0100
> 
> Let the wordsmithing begin!

Thanks, this is fine, with two gotchas:

> +is available.  Note that because of this use of a subprocess, native
> +compilation may produce warning and errors which byte-compilation does
> +not, and lisp code may thus need to be modified to work correctly. See
                                                                    ^^
Two spaces there, please.

> +@code{native-comp-async-report-warnings-errors} in @xref{Native-Compilation

@xref is inappropriate in the middle of a sentence, since it produces
a capitalized "See".  You want @pxref instead.

> Regarding discoverability, the
> *Warnings* buffer has entries like this:
> 
>     Warning (comp): tex-site.el:168:31: Warning: the function
>     ‘BibTeX-auto-store’ is not known to be defined. Disable showing
>     Disable logging
> 
> I guess we could add a link to
> `native-comp-async-report-warnings-errors' when the warning type == (comp)

We could, yes.  Assuming the code to add that is simple enough to
install on the release branch.

Thanks.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-07 14:15                   ` Eli Zaretskii
@ 2021-12-07 20:20                     ` Lars Ingebrigtsen
  0 siblings, 0 replies; 63+ messages in thread
From: Lars Ingebrigtsen @ 2021-12-07 20:20 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rpluim, stefankangas, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> If the user visits a Lisp file and clicks the Emacs Lisp->Byte Compile
> item on the menu bar, we do pop up the compilation log buffer with the
> warnings and errors, right?

That is an explicit action, so I don't think it applies here.

> And if the user installs or upgrades a package from ELPA, and the
> package is byte-compiled, the messages from that are shown, right?

That is quite similar to the native-comp situation, yes.

> So it sounds like we already show these messages to users, and this is
> just another such situation.  Once we decided to have JIT native
> compilation (and IMO it wouldn't make sense to decide differently), we
> should also agree to this side effect of compiling code in the
> background.

The problem is that the JIT can happen at any point, without the user
having done anything explicitly.  Anything that's autoloaded and fetched
when looking at *Help*, for instance, might trigger JIT and pop up
warnings to the user -- warnings that are 100% irrelevant for that user.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-07 17:16                               ` Eli Zaretskii
@ 2021-12-08  9:19                                 ` Robert Pluim
  2021-12-08 13:23                                   ` Eli Zaretskii
  0 siblings, 1 reply; 63+ messages in thread
From: Robert Pluim @ 2021-12-08  9:19 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: larsi, emacs-devel, stefankangas, akrl

>>>>> On Tue, 07 Dec 2021 19:16:16 +0200, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: akrl@sdf.org,  larsi@gnus.org,  stefankangas@gmail.com,
    >> emacs-devel@gnu.org
    >> Date: Tue, 07 Dec 2021 17:54:49 +0100
    >> 
    >> Let the wordsmithing begin!

    Eli> Thanks, this is fine, with two gotchas:

    >> +is available.  Note that because of this use of a subprocess, native
    >> +compilation may produce warning and errors which byte-compilation does
    >> +not, and lisp code may thus need to be modified to work correctly. See
    Eli>                                                                     ^^
    Eli> Two spaces there, please.

    >> +@code{native-comp-async-report-warnings-errors} in @xref{Native-Compilation

    Eli> @xref is inappropriate in the middle of a sentence, since it produces
    Eli> a capitalized "See".  You want @pxref instead.

Fixed and pushed to emacs-28.

    >> I guess we could add a link to
    >> `native-comp-async-report-warnings-errors' when the warning type == (comp)

    Eli> We could, yes.  Assuming the code to add that is simple enough to
    Eli> install on the release branch.

Something like this, although this puts the button on all warnings,
not just the ones about missing definitions. And now Iʼm tempted to
*remove* the 'Disable' buttons for 'comp' warnings, since clicking
those will suppress all native compilation warnings.

diff --git a/lisp/emacs-lisp/warnings.el b/lisp/emacs-lisp/warnings.el
index 36b275e2d3..8aa6d18d61 100644
--- a/lisp/emacs-lisp/warnings.el
+++ b/lisp/emacs-lisp/warnings.el
@@ -298,6 +298,12 @@ display-warning
               ;; Don't output the buttons when doing batch compilation
               ;; and similar.
               (unless (or noninteractive (eq type 'bytecomp))
+                (when (eq type 'comp)
+                  (insert " ")
+                  (insert-button "More Info"
+                                 'help-echo "mouse-2, RET: Show native-compile documentation"
+                                 'action (lambda (_)
+                                           (describe-variable 'native-comp-async-report-warnings-errors))))
                 (insert " ")
                 (insert-button "Disable showing"
                                'type 'warning-suppress-warning

(I really must either update some packages or hassle their
authors. Iʼm getting like 200 warnings)

Robert
-- 



^ permalink raw reply related	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-08  9:19                                 ` Robert Pluim
@ 2021-12-08 13:23                                   ` Eli Zaretskii
  2021-12-08 13:46                                     ` Andrea Corallo
  0 siblings, 1 reply; 63+ messages in thread
From: Eli Zaretskii @ 2021-12-08 13:23 UTC (permalink / raw)
  To: Robert Pluim; +Cc: larsi, emacs-devel, stefankangas, akrl

> From: Robert Pluim <rpluim@gmail.com>
> Cc: akrl@sdf.org,  larsi@gnus.org,  stefankangas@gmail.com,
>   emacs-devel@gnu.org
> Date: Wed, 08 Dec 2021 10:19:59 +0100
> 
>     >> I guess we could add a link to
>     >> `native-comp-async-report-warnings-errors' when the warning type == (comp)
> 
>     Eli> We could, yes.  Assuming the code to add that is simple enough to
>     Eli> install on the release branch.
> 
> Something like this, although this puts the button on all warnings,
> not just the ones about missing definitions.

Opinions about such a change, anyone?

> And now Iʼm tempted to
> *remove* the 'Disable' buttons for 'comp' warnings, since clicking
> those will suppress all native compilation warnings.

It was added there to do precisely that, so I think removing it would
be a step back.

Thanks.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-08 13:23                                   ` Eli Zaretskii
@ 2021-12-08 13:46                                     ` Andrea Corallo
  0 siblings, 0 replies; 63+ messages in thread
From: Andrea Corallo @ 2021-12-08 13:46 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Robert Pluim, emacs-devel, larsi, stefankangas

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Robert Pluim <rpluim@gmail.com>
>> Cc: akrl@sdf.org,  larsi@gnus.org,  stefankangas@gmail.com,
>>   emacs-devel@gnu.org
>> Date: Wed, 08 Dec 2021 10:19:59 +0100
>> 
>>     >> I guess we could add a link to
>>     >> `native-comp-async-report-warnings-errors' when the warning type == (comp)
>> 
>>     Eli> We could, yes.  Assuming the code to add that is simple enough to
>>     Eli> install on the release branch.
>> 
>> Something like this, although this puts the button on all warnings,
>> not just the ones about missing definitions.
>
> Opinions about such a change, anyone?

Sounds to me it might be useful to users.

  Andrea



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-06 20:26               ` Eli Zaretskii
  2021-12-07  7:51                 ` Lars Ingebrigtsen
@ 2021-12-17 18:14                 ` Stefan Kangas
  2021-12-17 19:12                   ` Eli Zaretskii
  1 sibling, 1 reply; 63+ messages in thread
From: Stefan Kangas @ 2021-12-17 18:14 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rpluim, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> Then flip it.  For yourself.  Why decide for all the others?

I have been reluctant to do that, as that would stop me from testing how
it works by default.

> But if "by popular demand" and other pressure, you will decide to
> disable the warnings nonetheless, I won't mount the barricades.  My
> opinion about this is unchanged, but feel free to disregard it.

I just recompiled, and I'm sitting again with mostly unusable Emacs for
the last 5-10 minutes or so.  Warnings popping up in the middle of
searches and trying to get things done.

For example, while writing this email, I was helpfully informed (among
other things) that:

Warning (comp): yasnippet.el:477:1: Warning: defvar
`yas-after-exit-snippet-hook' docstring wider than 80 characters
Disable showing Disable logging

I find the current situation untenable, especially if we expect some
high profile GNU/Linux distributions to be shipping
--with-native-compilation by default.

Unless there is a specific request not to do that from the maintainers,
I intend to flip the default to `silent' on emacs-28 in the next couple
of days.  If there is such a request, I will not insist further.

Thanks in advance.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-17 18:14                 ` Stefan Kangas
@ 2021-12-17 19:12                   ` Eli Zaretskii
  2021-12-17 19:27                     ` Óscar Fuentes
  2021-12-17 19:36                     ` Stefan Kangas
  0 siblings, 2 replies; 63+ messages in thread
From: Eli Zaretskii @ 2021-12-17 19:12 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: rpluim, emacs-devel

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 17 Dec 2021 10:14:43 -0800
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > But if "by popular demand" and other pressure, you will decide to
> > disable the warnings nonetheless, I won't mount the barricades.  My
> > opinion about this is unchanged, but feel free to disregard it.
> 
> Unless there is a specific request not to do that from the maintainers,
> I intend to flip the default to `silent' on emacs-28 in the next couple
> of days.  If there is such a request, I will not insist further.

When I said "by popular demand", I meant that.  Just your own voice is
not enough, IMO.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-17 19:12                   ` Eli Zaretskii
@ 2021-12-17 19:27                     ` Óscar Fuentes
  2021-12-17 19:36                     ` Stefan Kangas
  1 sibling, 0 replies; 63+ messages in thread
From: Óscar Fuentes @ 2021-12-17 19:27 UTC (permalink / raw)
  To: emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> Unless there is a specific request not to do that from the maintainers,
>> I intend to flip the default to `silent' on emacs-28 in the next couple
>> of days.  If there is such a request, I will not insist further.
>
> When I said "by popular demand", I meant that.  Just your own voice is
> not enough, IMO.

My vote is for 'silent too.

As explained on previous messages, I already have nil assigned to that
variable, so I don't care about the outcome of this decission as a user.

I do care as the maintainer of the MSYS2/Mingw-w64 Emacs package,
though.




^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-17 19:12                   ` Eli Zaretskii
  2021-12-17 19:27                     ` Óscar Fuentes
@ 2021-12-17 19:36                     ` Stefan Kangas
  2021-12-17 20:07                       ` Stefan Kangas
  1 sibling, 1 reply; 63+ messages in thread
From: Stefan Kangas @ 2021-12-17 19:36 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rpluim, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

> When I said "by popular demand", I meant that.  Just your own voice is
> not enough, IMO.

It seems like we are interpreting the popular opinion quite differently.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-17 19:36                     ` Stefan Kangas
@ 2021-12-17 20:07                       ` Stefan Kangas
  2021-12-17 20:38                         ` Eli Zaretskii
                                           ` (2 more replies)
  0 siblings, 3 replies; 63+ messages in thread
From: Stefan Kangas @ 2021-12-17 20:07 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rpluim, emacs-devel

> Eli Zaretskii <eliz@gnu.org> writes:
>
>> When I said "by popular demand", I meant that.  Just your own voice is
>> not enough, IMO.

I have now reviewed this thread, and changing the default from nil to
silent has the support from Robert Pluim, Stefan Kangas, Lars
Ingebrigtsen, Andrea Corallo and Óscar Fuentes (5).

For keeping the current default I count Eli Zaretskii (1).

Neutral in this thread are T.V. Raman and Stefan Monnier (2).

IOW, there is a clear majority in favor of the proposed change.  However
you choose to interpret this data, saying that this is "just my voice"
is clearly incorrect.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-17 20:07                       ` Stefan Kangas
@ 2021-12-17 20:38                         ` Eli Zaretskii
  2021-12-17 20:53                           ` Dmitry Gutov
  2021-12-17 21:10                           ` Stefan Kangas
  2021-12-18  0:24                         ` Po Lu
  2021-12-20  8:29                         ` Andrea Corallo
  2 siblings, 2 replies; 63+ messages in thread
From: Eli Zaretskii @ 2021-12-17 20:38 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: rpluim, emacs-devel

> From: Stefan Kangas <stefankangas@gmail.com>
> Date: Fri, 17 Dec 2021 12:07:07 -0800
> Cc: rpluim@gmail.com, emacs-devel@gnu.org
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >> When I said "by popular demand", I meant that.  Just your own voice is
> >> not enough, IMO.
> 
> I have now reviewed this thread, and changing the default from nil to
> silent has the support from Robert Pluim, Stefan Kangas, Lars
> Ingebrigtsen, Andrea Corallo and Óscar Fuentes (5).
> 
> For keeping the current default I count Eli Zaretskii (1).
> 
> Neutral in this thread are T.V. Raman and Stefan Monnier (2).
> 
> IOW, there is a clear majority in favor of the proposed change.  However
> you choose to interpret this data, saying that this is "just my voice"
> is clearly incorrect.

Sigh.  Here we go again:

  . if this annoys you so much, then why not change the value in your
    own configuration? why do you insist to change the default?
  . and if we eventually do change the default, why so early in the
    pretest? why not closer to the release?
  . and since when 5 vs 1 out of 8 means "by popular demand"?



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-17 20:38                         ` Eli Zaretskii
@ 2021-12-17 20:53                           ` Dmitry Gutov
  2021-12-17 21:20                             ` Colin Baxter 😺
                                               ` (2 more replies)
  2021-12-17 21:10                           ` Stefan Kangas
  1 sibling, 3 replies; 63+ messages in thread
From: Dmitry Gutov @ 2021-12-17 20:53 UTC (permalink / raw)
  To: Eli Zaretskii, Stefan Kangas; +Cc: rpluim, emacs-devel

On 17.12.2021 23:38, Eli Zaretskii wrote:
>    . if this annoys you so much, then why not change the value in your
>      own configuration? why do you insist to change the default?

FWIW, I've tried native-comp myself once, saw the myriad of warnings and 
returned to a non-native-compiled build in part because of that.

Just one voice, but there must be others who did that too.

>    . and if we eventually do change the default, why so early in the
>      pretest? why not closer to the release?

Closer SGTM. You could make a poll sometime before that.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-17 20:38                         ` Eli Zaretskii
  2021-12-17 20:53                           ` Dmitry Gutov
@ 2021-12-17 21:10                           ` Stefan Kangas
  1 sibling, 0 replies; 63+ messages in thread
From: Stefan Kangas @ 2021-12-17 21:10 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: rpluim, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>   . if this annoys you so much, then why not change the value in your
>     own configuration? why do you insist to change the default?

I have tried to explain in this thread how the current behavior is
surprising and bad.  Others have done so also.  What I have in my own
configuration is not relevant in that regard, I think.

>   . and if we eventually do change the default, why so early in the
>     pretest? why not closer to the release?

I don't have an opinion about the timing, but I do think it should
happen before Emacs 28.1.

>   . and since when 5 vs 1 out of 8 means "by popular demand"?

My claim was that 5 out of 8 is not "just one voice".

As I already said, I won't insist further so I will be bowing out of
this thread now.  Thanks.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-17 20:53                           ` Dmitry Gutov
@ 2021-12-17 21:20                             ` Colin Baxter 😺
  2021-12-17 22:01                             ` Ken Brown
  2021-12-17 22:10                             ` Rudolf Adamkovič
  2 siblings, 0 replies; 63+ messages in thread
From: Colin Baxter 😺 @ 2021-12-17 21:20 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Eli Zaretskii, emacs-devel, Stefan Kangas, rpluim

>>>>> Dmitry Gutov <dgutov@yandex.ru> writes:

    > On 17.12.2021 23:38, Eli Zaretskii wrote:
    >> . if this annoys you so much, then why not change the value in
    >> your own configuration? why do you insist to change the default?

    > FWIW, I've tried native-comp myself once, saw the myriad of
    > warnings and returned to a non-native-compiled build in part
    > because of that.

    > Just one voice, but there must be others who did that too.

I did exactly that a while ago - but then I'm just a nobody. :-)



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-17 20:53                           ` Dmitry Gutov
  2021-12-17 21:20                             ` Colin Baxter 😺
@ 2021-12-17 22:01                             ` Ken Brown
  2021-12-18  0:48                               ` Dmitry Gutov
  2021-12-17 22:10                             ` Rudolf Adamkovič
  2 siblings, 1 reply; 63+ messages in thread
From: Ken Brown @ 2021-12-17 22:01 UTC (permalink / raw)
  To: Dmitry Gutov, Eli Zaretskii, Stefan Kangas; +Cc: rpluim, emacs-devel

On 12/17/2021 3:53 PM, Dmitry Gutov wrote:
> On 17.12.2021 23:38, Eli Zaretskii wrote:
>>    . if this annoys you so much, then why not change the value in your
>>      own configuration? why do you insist to change the default?
> 
> FWIW, I've tried native-comp myself once, saw the myriad of warnings and 
> returned to a non-native-compiled build in part because of that.
> 
> Just one voice, but there must be others who did that too.

One more voice: I'm in favor of the current default for 
native-comp-async-report-warnings-errors.

Native compilation is disabled by default.  People who build emacs for their own 
use and choose to try native compilation can see the consequences and make their 
own decision on how to deal with them.  Users who don't like the warnings can 
turn them off.  Users who would rather help fix the problems turned up the 
warnings can leave them on.  Users who just find the whole issue annoying can 
stop building with native compilation.  But if we turned off the warnings by 
default, many users wouldn't even know the options.

Similar remarks apply to people who build emacs as maintainers for a distro.  If 
they choose to build with native compilation and impose that decision on their 
users, they can also choose for their users the default value of 
native-comp-async-report-warnings-errors.

If native compilation were enabled by default, it would be a different story.

Ken



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-17 20:53                           ` Dmitry Gutov
  2021-12-17 21:20                             ` Colin Baxter 😺
  2021-12-17 22:01                             ` Ken Brown
@ 2021-12-17 22:10                             ` Rudolf Adamkovič
  2 siblings, 0 replies; 63+ messages in thread
From: Rudolf Adamkovič @ 2021-12-17 22:10 UTC (permalink / raw)
  To: Dmitry Gutov, Eli Zaretskii, Stefan Kangas; +Cc: rpluim, emacs-devel

Dmitry Gutov <dgutov@yandex.ru> writes:

> FWIW, I've tried native-comp myself once, saw the myriad of warnings and 
> returned to a non-native-compiled build in part because of that.

Same here and +1 vote.  I eventually found the variable, but who has the
time to fiddle with this?  Also, +1 for silencing the warnings when
installing or upgrading packages.

-- 
"'Contrariwise,' continued Tweedledee, 'if it was so, it might be; and
if it were so, it would be; but as it isn't, it ain't. That's logic.'"
-- Lewis Carroll, Through the Looking Glass

Rudolf Adamkovič <salutis@me.com> [he/him]
Studenohorská 25
84103 Bratislava
Slovakia



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-17 20:07                       ` Stefan Kangas
  2021-12-17 20:38                         ` Eli Zaretskii
@ 2021-12-18  0:24                         ` Po Lu
  2021-12-20  8:29                         ` Andrea Corallo
  2 siblings, 0 replies; 63+ messages in thread
From: Po Lu @ 2021-12-18  0:24 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Eli Zaretskii, rpluim, emacs-devel

Stefan Kangas <stefankangas@gmail.com> writes:

> For keeping the current default I count Eli Zaretskii (1).

FWIW, I support the current default as well.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-17 22:01                             ` Ken Brown
@ 2021-12-18  0:48                               ` Dmitry Gutov
  2021-12-18 14:38                                 ` Ken Brown
  0 siblings, 1 reply; 63+ messages in thread
From: Dmitry Gutov @ 2021-12-18  0:48 UTC (permalink / raw)
  To: Ken Brown, Eli Zaretskii, Stefan Kangas; +Cc: rpluim, emacs-devel

On 18.12.2021 01:01, Ken Brown wrote:

> Native compilation is disabled by default.  People who build emacs for 
> their own use and choose to try native compilation can see the 
> consequences and make their own decision on how to deal with them.

I agree that as long as we don't intend for it to be on by default, the 
warnings are fine to show.

> Similar remarks apply to people who build emacs as maintainers for a 
> distro.  If they choose to build with native compilation and impose that 
> decision on their users, they can also choose for their users the 
> default value of native-comp-async-report-warnings-errors.

This, however, seems like a bad idea.

The distros don't control, nor are responsible for, the whole 
third-party package ecosystem.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-18  0:48                               ` Dmitry Gutov
@ 2021-12-18 14:38                                 ` Ken Brown
  2021-12-18 16:58                                   ` Óscar Fuentes
  0 siblings, 1 reply; 63+ messages in thread
From: Ken Brown @ 2021-12-18 14:38 UTC (permalink / raw)
  To: Dmitry Gutov, Eli Zaretskii, Stefan Kangas; +Cc: rpluim, emacs-devel

On 12/17/2021 7:48 PM, Dmitry Gutov wrote:
> On 18.12.2021 01:01, Ken Brown wrote:
> 
>> Native compilation is disabled by default.  People who build emacs for their 
>> own use and choose to try native compilation can see the consequences and make 
>> their own decision on how to deal with them.
> 
> I agree that as long as we don't intend for it to be on by default, the warnings 
> are fine to show.
> 
>> Similar remarks apply to people who build emacs as maintainers for a distro.  
>> If they choose to build with native compilation and impose that decision on 
>> their users, they can also choose for their users the default value of 
>> native-comp-async-report-warnings-errors.
> 
> This, however, seems like a bad idea.
> 
> The distros don't control, nor are responsible for, the whole third-party 
> package ecosystem.

Right, which is why distros might well choose to disable warnings.  My point is 
that it's their decision, given that they've already decided to build with 
native compilation, not something that Emacs has to worry about.

Ken



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-18 14:38                                 ` Ken Brown
@ 2021-12-18 16:58                                   ` Óscar Fuentes
  2021-12-18 20:51                                     ` Ken Brown
  0 siblings, 1 reply; 63+ messages in thread
From: Óscar Fuentes @ 2021-12-18 16:58 UTC (permalink / raw)
  To: emacs-devel

Ken Brown <kbrown@cornell.edu> writes:

> On 12/17/2021 7:48 PM, Dmitry Gutov wrote:
>> On 18.12.2021 01:01, Ken Brown wrote:
>> 
>>> Native compilation is disabled by default.  People who build emacs
>>> for their own use and choose to try native compilation can see the
>>> consequences and make their own decision on how to deal with them.
>> I agree that as long as we don't intend for it to be on by default,
>> the warnings are fine to show.
>> 
>>> Similar remarks apply to people who build emacs as maintainers for
>>> a distro.  If they choose to build with native compilation and
>>> impose that decision on their users, they can also choose for their
>>> users the default value of
>>> native-comp-async-report-warnings-errors.
>> This, however, seems like a bad idea.
>> The distros don't control, nor are responsible for, the whole
>> third-party package ecosystem.
>
> Right, which is why distros might well choose to disable warnings.  My
> point is that it's their decision, given that they've already decided
> to build with native compilation, not something that Emacs has to
> worry about.

IIUC you are saying "that's what they deserve for using native-comp".

Well, building with native-comp enabled is a build configuration
supported by Emacs, changing the default value of
native-comp-async-report-warnings-errors requires patching Emacs or
providing a "vendor" configuration file.

Those are changes at a very different level.




^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-18 16:58                                   ` Óscar Fuentes
@ 2021-12-18 20:51                                     ` Ken Brown
  0 siblings, 0 replies; 63+ messages in thread
From: Ken Brown @ 2021-12-18 20:51 UTC (permalink / raw)
  To: Óscar Fuentes, emacs-devel

On 12/18/2021 11:58 AM, Óscar Fuentes wrote:
> Ken Brown <kbrown@cornell.edu> writes:
>> Right, which is why distros might well choose to disable warnings.  My
>> point is that it's their decision, given that they've already decided
>> to build with native compilation, not something that Emacs has to
>> worry about.
> 
> IIUC you are saying "that's what they deserve for using native-comp".

No, that's not what I meant, and I'm sorry if I gave that impression.  I like 
native-comp, I use it myself, and at some point I expect to release a version of 
emacs for the Cygwin distribution with native-comp enabled.  What I tried to say 
is that if maintainers choose to enable a build configuration that is not 
enabled by default, they should be aware of the consequences and should deal 
with those consequences as they see fit.

> Well, building with native-comp enabled is a build configuration
> supported by Emacs, changing the default value of
> native-comp-async-report-warnings-errors requires patching Emacs or
> providing a "vendor" configuration file
> Those are changes at a very different level.

Agreed.  And I don't see a problem with making changes at that level.

Ken



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-17 20:07                       ` Stefan Kangas
  2021-12-17 20:38                         ` Eli Zaretskii
  2021-12-18  0:24                         ` Po Lu
@ 2021-12-20  8:29                         ` Andrea Corallo
  2021-12-24  1:01                           ` Dmitry Gutov
  2 siblings, 1 reply; 63+ messages in thread
From: Andrea Corallo @ 2021-12-20  8:29 UTC (permalink / raw)
  To: Stefan Kangas; +Cc: Eli Zaretskii, rpluim, emacs-devel

Stefan Kangas <stefankangas@gmail.com> writes:

>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>>> When I said "by popular demand", I meant that.  Just your own voice is
>>> not enough, IMO.
>
> I have now reviewed this thread, and changing the default from nil to
> silent has the support from Robert Pluim, Stefan Kangas, Lars
> Ingebrigtsen, Andrea Corallo and Óscar Fuentes (5).
>
> For keeping the current default I count Eli Zaretskii (1).
>
> Neutral in this thread are T.V. Raman and Stefan Monnier (2).

FWIW please count me on the neutral side, I've no formed opinion on this
ATM even if the more time is passing the more I tend to think that the
current default might be safer and/or beneficial on the long run.

Thanks

  Andrea



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-20  8:29                         ` Andrea Corallo
@ 2021-12-24  1:01                           ` Dmitry Gutov
  2021-12-24  1:34                             ` T.V Raman
  2021-12-24  9:53                             ` Andrea Corallo
  0 siblings, 2 replies; 63+ messages in thread
From: Dmitry Gutov @ 2021-12-24  1:01 UTC (permalink / raw)
  To: Andrea Corallo, Stefan Kangas; +Cc: Eli Zaretskii, rpluim, emacs-devel

Hi Andrea,

On 20.12.2021 11:29, Andrea Corallo wrote:
> Stefan Kangas <stefankangas@gmail.com> writes:
> 
>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>
>>>> When I said "by popular demand", I meant that.  Just your own voice is
>>>> not enough, IMO.
>>
>> I have now reviewed this thread, and changing the default from nil to
>> silent has the support from Robert Pluim, Stefan Kangas, Lars
>> Ingebrigtsen, Andrea Corallo and Óscar Fuentes (5).
>>
>> For keeping the current default I count Eli Zaretskii (1).
>>
>> Neutral in this thread are T.V. Raman and Stefan Monnier (2).
> 
> FWIW please count me on the neutral side, I've no formed opinion on this
> ATM even if the more time is passing the more I tend to think that the
> current default might be safer and/or beneficial on the long run.

This might be a distracting aside, but could you comment on the idea 
that I think Stefan mentioned previously: that the native compiler could 
use not the original source files, but the byte-compiled *.elc files as 
the "source". By the time those are compiled, all the dependencies are 
resolved one way or another, right? So the user won't need to suffer the 
same kind of warnings again.

Do they contain the necessary information to do native-compile, and its 
various optimizations? If yes, are there any other difficulties 
associated with such an approach?



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-24  1:01                           ` Dmitry Gutov
@ 2021-12-24  1:34                             ` T.V Raman
  2021-12-24  9:53                             ` Andrea Corallo
  1 sibling, 0 replies; 63+ messages in thread
From: T.V Raman @ 2021-12-24  1:34 UTC (permalink / raw)
  To: Dmitry Gutov
  Cc: Andrea Corallo, Stefan Kangas, Eli Zaretskii, rpluim, emacs-devel

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

Dmitry Gutov <dgutov@yandex.ru> writes:


Thanks for bubbling this back up -- I think this is the real issue ---
and I too hope Andrea will address this last mile of native-comp ---
> Hi Andrea,
>
> On 20.12.2021 11:29, Andrea Corallo wrote:
>> Stefan Kangas <stefankangas@gmail.com> writes:
>> 
>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>
>>>>> When I said "by popular demand", I meant that.  Just your own voice is
>>>>> not enough, IMO.
>>>
>>> I have now reviewed this thread, and changing the default from nil to
>>> silent has the support from Robert Pluim, Stefan Kangas, Lars
>>> Ingebrigtsen, Andrea Corallo and 0ˆ7scar Fuentes (5).
>>>
>>> For keeping the current default I count Eli Zaretskii (1).
>>>
>>> Neutral in this thread are T.V. Raman and Stefan Monnier (2).
>> FWIW please count me on the neutral side, I've no formed opinion on
>> this
>> ATM even if the more time is passing the more I tend to think that the
>> current default might be safer and/or beneficial on the long run.
>
> This might be a distracting aside, but could you comment on the idea
> that I think Stefan mentioned previously: that the native compiler
> could use not the original source files, but the byte-compiled *.elc
> files as the "source". By the time those are compiled, all the
> dependencies are resolved one way or another, right? So the user won't
> need to suffer the same kind of warnings again.
>
> Do they contain the necessary information to do native-compile, and
> its various optimizations? If yes, are there any other difficulties
> associated with such an approach?
>

-- 

Thanks,

--Raman(I Search, I Find, I Misplace, I Research)
7©4 Id: kg:/m/0285kf1  •0Ü8



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-24  1:01                           ` Dmitry Gutov
  2021-12-24  1:34                             ` T.V Raman
@ 2021-12-24  9:53                             ` Andrea Corallo
  2021-12-25  0:05                               ` Dmitry Gutov
  1 sibling, 1 reply; 63+ messages in thread
From: Andrea Corallo @ 2021-12-24  9:53 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Eli Zaretskii, emacs-devel, Stefan Kangas, rpluim

Dmitry Gutov <dgutov@yandex.ru> writes:

> Hi Andrea,
>
> On 20.12.2021 11:29, Andrea Corallo wrote:
>> Stefan Kangas <stefankangas@gmail.com> writes:
>> 
>>>> Eli Zaretskii <eliz@gnu.org> writes:
>>>>
>>>>> When I said "by popular demand", I meant that.  Just your own voice is
>>>>> not enough, IMO.
>>>
>>> I have now reviewed this thread, and changing the default from nil to
>>> silent has the support from Robert Pluim, Stefan Kangas, Lars
>>> Ingebrigtsen, Andrea Corallo and Óscar Fuentes (5).
>>>
>>> For keeping the current default I count Eli Zaretskii (1).
>>>
>>> Neutral in this thread are T.V. Raman and Stefan Monnier (2).
>> FWIW please count me on the neutral side, I've no formed opinion on
>> this
>> ATM even if the more time is passing the more I tend to think that the
>> current default might be safer and/or beneficial on the long run.
>
> This might be a distracting aside, but could you comment on the idea
> that I think Stefan mentioned previously: that the native compiler
> could use not the original source files, but the byte-compiled *.elc
> files as the "source". By the time those are compiled, all the
> dependencies are resolved one way or another, right? So the user won't
> need to suffer the same kind of warnings again.
>
> Do they contain the necessary information to do native-compile, and
> its various optimizations? If yes, are there any other difficulties
> associated with such an approach?

Hi Dmitry,

this is not a trivial modification so I might easily miss some aspects
of it but...

Certanly bytecode ATM has no way to store declaration specifiers and
these are used for native compilation.  I guess we should at least
extend this first.

BR

  Andrea



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-24  9:53                             ` Andrea Corallo
@ 2021-12-25  0:05                               ` Dmitry Gutov
  2021-12-25 10:53                                 ` Andrea Corallo
  0 siblings, 1 reply; 63+ messages in thread
From: Dmitry Gutov @ 2021-12-25  0:05 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: Eli Zaretskii, emacs-devel, Stefan Kangas, rpluim

Hi Andrea,

On 24.12.2021 12:53, Andrea Corallo wrote:
> this is not a trivial modification so I might easily miss some aspects
> of it but...
> 
> Certanly bytecode ATM has no way to store declaration specifiers and
> these are used for native compilation.  I guess we should at least
> extend this first.

Thanks for the answer, I really wanted at least a high-level 
understanding of this point. I wouldn't presume to ask you to work on 
this, but maybe some of the others here who also complained about the 
warnings, would be interested in taking the initiative?

Regarding declaration specifiers, I think the new (declare (modes ...)) 
feature had the same problem.

Not sure how it was solved (or whether it was solved at all).



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-25  0:05                               ` Dmitry Gutov
@ 2021-12-25 10:53                                 ` Andrea Corallo
  2021-12-28  1:59                                   ` Dmitry Gutov
  0 siblings, 1 reply; 63+ messages in thread
From: Andrea Corallo @ 2021-12-25 10:53 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Eli Zaretskii, emacs-devel, Stefan Kangas, rpluim

Dmitry Gutov <dgutov@yandex.ru> writes:

> Hi Andrea,
>
> On 24.12.2021 12:53, Andrea Corallo wrote:
>> this is not a trivial modification so I might easily miss some aspects
>> of it but...
>> Certanly bytecode ATM has no way to store declaration specifiers and
>> these are used for native compilation.  I guess we should at least
>> extend this first.
>
> Thanks for the answer, I really wanted at least a high-level
> understanding of this point. I wouldn't presume to ask you to work on
> this, but maybe some of the others here who also complained about the
> warnings, would be interested in taking the initiative?
>
> Regarding declaration specifiers, I think the new (declare (modes
> ...)) feature had the same problem.
>
> Not sure how it was solved (or whether it was solved at all).

I guess the mode declaration has affect during byte compilation so it
should be fine.  The issue is for other declarations that are taking
effect afterwards in the native compilation pipeline.

As the bytecompiler pipeline was always assumed to be the only and last
compilation step, bytecode is ATM not designed to retain these
information.  I'm sure it's extensible somehow but we probably need some
advise on what's the best way to approach this.

BR

  Andrea



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-25 10:53                                 ` Andrea Corallo
@ 2021-12-28  1:59                                   ` Dmitry Gutov
  2021-12-30  9:37                                     ` Andrea Corallo
  0 siblings, 1 reply; 63+ messages in thread
From: Dmitry Gutov @ 2021-12-28  1:59 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: Eli Zaretskii, emacs-devel, Stefan Kangas, rpluim

On 25.12.2021 13:53, Andrea Corallo wrote:
> Dmitry Gutov <dgutov@yandex.ru> writes:
> 
>> Hi Andrea,
>>
>> On 24.12.2021 12:53, Andrea Corallo wrote:
>>> this is not a trivial modification so I might easily miss some aspects
>>> of it but...
>>> Certanly bytecode ATM has no way to store declaration specifiers and
>>> these are used for native compilation.  I guess we should at least
>>> extend this first.
>>
>> Thanks for the answer, I really wanted at least a high-level
>> understanding of this point. I wouldn't presume to ask you to work on
>> this, but maybe some of the others here who also complained about the
>> warnings, would be interested in taking the initiative?
>>
>> Regarding declaration specifiers, I think the new (declare (modes
>> ...)) feature had the same problem.
>>
>> Not sure how it was solved (or whether it was solved at all).
> 
> I guess the mode declaration has affect during byte compilation so it
> should be fine.  The issue is for other declarations that are taking
> effect afterwards in the native compilation pipeline.

It has an effect at runtime: Emacs needs to look up those properties 
after the byte code is evaluated. That's why .elc files have additional 
forms added which basically call 'function-put' (as set up in 
defun-declarations-alist).

But...

> As the bytecompiler pipeline was always assumed to be the only and last
> compilation step, bytecode is ATM not designed to retain these
> information.  I'm sure it's extensible somehow but we probably need some
> advise on what's the best way to approach this.

...I suppose you might want to access that information without 
evaluating said additional byte code forms either.

Or could it evaluate them anyway? If native compilation happens after 
the code is loaded, the symbols will have the necessary properties then.



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-28  1:59                                   ` Dmitry Gutov
@ 2021-12-30  9:37                                     ` Andrea Corallo
  2022-01-08  2:29                                       ` Dmitry Gutov
  0 siblings, 1 reply; 63+ messages in thread
From: Andrea Corallo @ 2021-12-30  9:37 UTC (permalink / raw)
  To: Dmitry Gutov; +Cc: Eli Zaretskii, emacs-devel, Stefan Kangas, rpluim

Dmitry Gutov <dgutov@yandex.ru> writes:

> On 25.12.2021 13:53, Andrea Corallo wrote:
>> Dmitry Gutov <dgutov@yandex.ru> writes:
>> 
>>> Hi Andrea,
>>>
>>> On 24.12.2021 12:53, Andrea Corallo wrote:
>>>> this is not a trivial modification so I might easily miss some aspects
>>>> of it but...
>>>> Certanly bytecode ATM has no way to store declaration specifiers and
>>>> these are used for native compilation.  I guess we should at least
>>>> extend this first.
>>>
>>> Thanks for the answer, I really wanted at least a high-level
>>> understanding of this point. I wouldn't presume to ask you to work on
>>> this, but maybe some of the others here who also complained about the
>>> warnings, would be interested in taking the initiative?
>>>
>>> Regarding declaration specifiers, I think the new (declare (modes
>>> ...)) feature had the same problem.
>>>
>>> Not sure how it was solved (or whether it was solved at all).
>> I guess the mode declaration has affect during byte compilation so
>> it
>> should be fine.  The issue is for other declarations that are taking
>> effect afterwards in the native compilation pipeline.
>
> It has an effect at runtime: Emacs needs to look up those properties
> after the byte code is evaluated. That's why .elc files have
> additional forms added which basically call 'function-put' (as set up
> in defun-declarations-alist).

Indeed it has effect in the runtime.  But as you say this is because the
byte compiler generates different code for that (in this case a top
level form).  In the case of the native compiler we'd need to store and
reuse a bunch of information for following native compilation that has
to happen after.

> But...
>
>> As the bytecompiler pipeline was always assumed to be the only and last
>> compilation step, bytecode is ATM not designed to retain these
>> information.  I'm sure it's extensible somehow but we probably need some
>> advise on what's the best way to approach this.
>
> ...I suppose you might want to access that information without
> evaluating said additional byte code forms either.
>
> Or could it evaluate them anyway? If native compilation happens after
> the code is loaded, the symbols will have the necessary properties
> then.

Maybe a sufficient solution is an ad hoc local variable emitted (when
necessary) in the .elc file with like an a-list function -> declaration
specifiers we are interested in?

  Andrea



^ permalink raw reply	[flat|nested] 63+ messages in thread

* Re: native-comp-async-report-warnings-errors default value
  2021-12-30  9:37                                     ` Andrea Corallo
@ 2022-01-08  2:29                                       ` Dmitry Gutov
  0 siblings, 0 replies; 63+ messages in thread
From: Dmitry Gutov @ 2022-01-08  2:29 UTC (permalink / raw)
  To: Andrea Corallo; +Cc: Eli Zaretskii, emacs-devel, Stefan Kangas, rpluim

On 30.12.2021 11:37, Andrea Corallo wrote:

> Indeed it has effect in the runtime.  But as you say this is because the
> byte compiler generates different code for that (in this case a top
> level form).  In the case of the native compiler we'd need to store and
> reuse a bunch of information for following native compilation that has
> to happen after.

Store in .elc files, I take it.

>> But...
>>
>>> As the bytecompiler pipeline was always assumed to be the only and last
>>> compilation step, bytecode is ATM not designed to retain these
>>> information.  I'm sure it's extensible somehow but we probably need some
>>> advise on what's the best way to approach this.
>>
>> ...I suppose you might want to access that information without
>> evaluating said additional byte code forms either.
>>
>> Or could it evaluate them anyway? If native compilation happens after
>> the code is loaded, the symbols will have the necessary properties
>> then.
> 
> Maybe a sufficient solution is an ad hoc local variable emitted (when
> necessary) in the .elc file with like an a-list function -> declaration
> specifiers we are interested in?

I was even going to suggest that you would parse those (byte-code ...) 
forms in compiled files -- as long as they actually vary very little, it 
could be handled by a small interpreter.

But maybe we could keep those forms uncompiled without a significant 
performance downside? Someone could benchmark that. Then the .elc files 
would just contain (function-put ...) on top-level instead.

Or if you really need the declarations available before the 
corresponding functions are defined (I don't know if you compile every 
encountered function right away, or wait until the whole file is 
parsed), the order of forms in .elc files could be swapped: first 
property declaration, then definition.



^ permalink raw reply	[flat|nested] 63+ messages in thread

end of thread, other threads:[~2022-01-08  2:29 UTC | newest]

Thread overview: 63+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-10-14 11:23 native-comp-async-report-warnings-errors default value Robert Pluim
2021-10-14 11:30 ` Eli Zaretskii
2021-10-14 11:43   ` Robert Pluim
2021-10-14 11:52     ` Eli Zaretskii
2021-10-14 14:48       ` Robert Pluim
2021-10-14 15:57         ` Eli Zaretskii
2021-10-14 16:42           ` Lars Ingebrigtsen
2021-10-14 16:47             ` Eli Zaretskii
2021-10-15  8:51           ` Robert Pluim
2021-10-14 12:07     ` Stefan Kangas
2021-10-14 12:12       ` Eli Zaretskii
2021-12-02 17:03     ` Stefan Kangas
2021-12-02 17:10       ` Lars Ingebrigtsen
2021-12-02 17:14         ` Andrea Corallo
2021-12-02 21:15           ` T.V Raman
2021-12-02 18:23       ` Eli Zaretskii
2021-12-02 19:27         ` Stefan Kangas
2021-12-02 19:42           ` Eli Zaretskii
2021-12-06 20:11             ` Stefan Kangas
2021-12-06 20:26               ` Eli Zaretskii
2021-12-07  7:51                 ` Lars Ingebrigtsen
2021-12-07  9:37                   ` Andrea Corallo
2021-12-07  9:42                     ` Robert Pluim
2021-12-07  9:54                       ` Andrea Corallo
2021-12-07 12:38                         ` Robert Pluim
2021-12-07 14:28                           ` Eli Zaretskii
2021-12-07 16:54                             ` Robert Pluim
2021-12-07 17:16                               ` Eli Zaretskii
2021-12-08  9:19                                 ` Robert Pluim
2021-12-08 13:23                                   ` Eli Zaretskii
2021-12-08 13:46                                     ` Andrea Corallo
2021-12-07 13:24                     ` Stefan Monnier
2021-12-07 14:05                       ` Andrea Corallo
2021-12-07 14:33                         ` Eli Zaretskii
2021-12-07 14:15                   ` Eli Zaretskii
2021-12-07 20:20                     ` Lars Ingebrigtsen
2021-12-17 18:14                 ` Stefan Kangas
2021-12-17 19:12                   ` Eli Zaretskii
2021-12-17 19:27                     ` Óscar Fuentes
2021-12-17 19:36                     ` Stefan Kangas
2021-12-17 20:07                       ` Stefan Kangas
2021-12-17 20:38                         ` Eli Zaretskii
2021-12-17 20:53                           ` Dmitry Gutov
2021-12-17 21:20                             ` Colin Baxter 😺
2021-12-17 22:01                             ` Ken Brown
2021-12-18  0:48                               ` Dmitry Gutov
2021-12-18 14:38                                 ` Ken Brown
2021-12-18 16:58                                   ` Óscar Fuentes
2021-12-18 20:51                                     ` Ken Brown
2021-12-17 22:10                             ` Rudolf Adamkovič
2021-12-17 21:10                           ` Stefan Kangas
2021-12-18  0:24                         ` Po Lu
2021-12-20  8:29                         ` Andrea Corallo
2021-12-24  1:01                           ` Dmitry Gutov
2021-12-24  1:34                             ` T.V Raman
2021-12-24  9:53                             ` Andrea Corallo
2021-12-25  0:05                               ` Dmitry Gutov
2021-12-25 10:53                                 ` Andrea Corallo
2021-12-28  1:59                                   ` Dmitry Gutov
2021-12-30  9:37                                     ` Andrea Corallo
2022-01-08  2:29                                       ` Dmitry Gutov
2021-12-02 21:14       ` T.V Raman
2021-12-03  6:50         ` Eli Zaretskii

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).