* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-07-30 5:43 ` Eli Zaretskii
@ 2021-07-30 10:55 ` Lars Ingebrigtsen
2021-07-30 11:03 ` Eli Zaretskii
2021-07-30 17:54 ` Juri Linkov
2021-07-30 22:03 ` Stefan Monnier
2 siblings, 1 reply; 24+ messages in thread
From: Lars Ingebrigtsen @ 2021-07-30 10:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, Stefan Monnier, leungbk, juri
Eli Zaretskii <eliz@gnu.org> writes:
> I'm not sure it's a warning. It's an informative message, and some of
> them are always displayed during bootstrap. Making them warnings
> would then apply pressure on us to remove them, which we cannot easily
> do in the case of those other messages (unlike the one caused by the
> changeset in this bug).
It informs about an unfortunate situation that should be fixed (and we
have indeed fixed them all). So it's a warning to me.
> My personal advice is to read carefully every line displayed by the
> build process, and not limit yourself to warnings. Messages that
> aren't supposed to appear during a normal build should be discovered
> regardless of whether they are warnings/errors or not.
On the other hand, my personal advice is to use admin/emake, which
filters out all the junk so that you don't have to read anything
carefully. :-)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-07-30 10:55 ` Lars Ingebrigtsen
@ 2021-07-30 11:03 ` Eli Zaretskii
2021-07-30 11:16 ` Lars Ingebrigtsen
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2021-07-30 11:03 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel, monnier, leungbk, juri
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>, juri@linkov.net,
> leungbk@mailfence.com, emacs-devel@gnu.org
> Date: Fri, 30 Jul 2021 12:55:29 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > I'm not sure it's a warning. It's an informative message, and some of
> > them are always displayed during bootstrap. Making them warnings
> > would then apply pressure on us to remove them, which we cannot easily
> > do in the case of those other messages (unlike the one caused by the
> > changeset in this bug).
>
> It informs about an unfortunate situation that should be fixed (and we
> have indeed fixed them all). So it's a warning to me.
We cannot do anything with some theses "warnings" shown at bootstrap
time, so how would it be useful to display warnings there?
> > My personal advice is to read carefully every line displayed by the
> > build process, and not limit yourself to warnings. Messages that
> > aren't supposed to appear during a normal build should be discovered
> > regardless of whether they are warnings/errors or not.
>
> On the other hand, my personal advice is to use admin/emake, which
> filters out all the junk so that you don't have to read anything
> carefully. :-)
I think this is sub-optimal, at least for active developers of Emacs.
No one said a message shown by the build is only important when it's a
warning.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-07-30 11:03 ` Eli Zaretskii
@ 2021-07-30 11:16 ` Lars Ingebrigtsen
2021-07-30 12:13 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Lars Ingebrigtsen @ 2021-07-30 11:16 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, monnier, leungbk, juri
Eli Zaretskii <eliz@gnu.org> writes:
> We cannot do anything with some theses "warnings" shown at bootstrap
> time, so how would it be useful to display warnings there?
I don't get any warnings when saying "make bootstrap"? Which ones are
you referring to?
>> On the other hand, my personal advice is to use admin/emake, which
>> filters out all the junk so that you don't have to read anything
>> carefully. :-)
>
> I think this is sub-optimal, at least for active developers of Emacs.
> No one said a message shown by the build is only important when it's a
> warning.
emake doesn't filter out everything that's a not a warning, so I don't
follow you here.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-07-30 11:16 ` Lars Ingebrigtsen
@ 2021-07-30 12:13 ` Eli Zaretskii
2021-07-30 12:20 ` Lars Ingebrigtsen
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2021-07-30 12:13 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel, monnier, leungbk, juri
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca, juri@linkov.net, leungbk@mailfence.com,
> emacs-devel@gnu.org
> Date: Fri, 30 Jul 2021 13:16:10 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > We cannot do anything with some theses "warnings" shown at bootstrap
> > time, so how would it be useful to display warnings there?
>
> I don't get any warnings when saying "make bootstrap"? Which ones are
> you referring to?
Generating loaddefs.el in a clean repository always reports a couple
of prefixes it won't register, and for a good reason.
> >> On the other hand, my personal advice is to use admin/emake, which
> >> filters out all the junk so that you don't have to read anything
> >> carefully. :-)
> >
> > I think this is sub-optimal, at least for active developers of Emacs.
> > No one said a message shown by the build is only important when it's a
> > warning.
>
> emake doesn't filter out everything that's a not a warning, so I don't
> follow you here.
Then I don't understand why you mentioned it.
Juri wants this to be a warning because evidently he disregards (or
maybe actually filters out) anything that isn't a warning or an error
message. That's why I said other messages are also worthy of us
paying attention.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-07-30 12:13 ` Eli Zaretskii
@ 2021-07-30 12:20 ` Lars Ingebrigtsen
2021-07-30 13:22 ` Eli Zaretskii
0 siblings, 1 reply; 24+ messages in thread
From: Lars Ingebrigtsen @ 2021-07-30 12:20 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, monnier, leungbk, juri
Eli Zaretskii <eliz@gnu.org> writes:
> Generating loaddefs.el in a clean repository always reports a couple
> of prefixes it won't register, and for a good reason.
It doesn't do that here -- perhaps it's in the Windows-specific bits?
(Stefan, Stefan and I fixed all those prefix warnings in the GNU Linux
build a few years ago, if I recall correctly.)
>> emake doesn't filter out everything that's a not a warning, so I don't
>> follow you here.
>
> Then I don't understand why you mentioned it.
Because it filters out everything that's irrelevant.
> Juri wants this to be a warning because evidently he disregards (or
> maybe actually filters out) anything that isn't a warning or an error
> message. That's why I said other messages are also worthy of us
> paying attention.
I agree, but you said you had to read the output carefully, and I
pointed out that that's not necessary if you use admin/emake.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-07-30 12:20 ` Lars Ingebrigtsen
@ 2021-07-30 13:22 ` Eli Zaretskii
2021-07-30 14:39 ` Lars Ingebrigtsen
0 siblings, 1 reply; 24+ messages in thread
From: Eli Zaretskii @ 2021-07-30 13:22 UTC (permalink / raw)
To: Lars Ingebrigtsen; +Cc: emacs-devel, monnier, leungbk, juri
> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: monnier@iro.umontreal.ca, juri@linkov.net, leungbk@mailfence.com,
> emacs-devel@gnu.org
> Date: Fri, 30 Jul 2021 14:20:53 +0200
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Generating loaddefs.el in a clean repository always reports a couple
> > of prefixes it won't register, and for a good reason.
>
> It doesn't do that here -- perhaps it's in the Windows-specific bits?
> (Stefan, Stefan and I fixed all those prefix warnings in the GNU Linux
> build a few years ago, if I recall correctly.)
Hmm... I rarely bootstrap, so I guess my memories are outdated. But
"years ago" doesn't sound right to me -- could you tell which changes
removed those "Not registering..." messages during the initial build?
Anyway, if the intent is to fix any such message if and when it
appears, seeing none of them as legitimate, then it's okay to make it
a warning.
> >> emake doesn't filter out everything that's a not a warning, so I don't
> >> follow you here.
> >
> > Then I don't understand why you mentioned it.
>
> Because it filters out everything that's irrelevant.
>
> > Juri wants this to be a warning because evidently he disregards (or
> > maybe actually filters out) anything that isn't a warning or an error
> > message. That's why I said other messages are also worthy of us
> > paying attention.
>
> I agree, but you said you had to read the output carefully, and I
> pointed out that that's not necessary if you use admin/emake.
Which means we are in violent agreement, right?
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-07-30 13:22 ` Eli Zaretskii
@ 2021-07-30 14:39 ` Lars Ingebrigtsen
0 siblings, 0 replies; 24+ messages in thread
From: Lars Ingebrigtsen @ 2021-07-30 14:39 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: emacs-devel, monnier, leungbk, juri
Eli Zaretskii <eliz@gnu.org> writes:
> Hmm... I rarely bootstrap, so I guess my memories are outdated. But
> "years ago" doesn't sound right to me -- could you tell which changes
> removed those "Not registering..." messages during the initial build?
It was in that never-ending thread on emacs-devel called "Towards a
Cleaner Emacs Build"... Which happened in 2019, apparently.
> Anyway, if the intent is to fix any such message if and when it
> appears, seeing none of them as legitimate, then it's okay to make it
> a warning.
Yes, I think so.
> Which means we are in violent agreement, right?
Indeed.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-07-30 5:43 ` Eli Zaretskii
2021-07-30 10:55 ` Lars Ingebrigtsen
@ 2021-07-30 17:54 ` Juri Linkov
2021-07-30 18:26 ` Eli Zaretskii
2021-07-30 22:08 ` Stefan Monnier
2021-07-30 22:03 ` Stefan Monnier
2 siblings, 2 replies; 24+ messages in thread
From: Juri Linkov @ 2021-07-30 17:54 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, Stefan Monnier, leungbk, emacs-devel
> I'm not sure it's a warning. It's an informative message, and some of
> them are always displayed during bootstrap. Making them warnings
> would then apply pressure on us to remove them, which we cannot easily
> do in the case of those other messages (unlike the one caused by the
> changeset in this bug).
For example, today's compilation displayed as lot of such lines:
Warning: Eager macro-expansion skipped due to cycle:
… => (load "byte-opt.el") => (macroexpand-all …
Warning: Eager macro-expansion skipped due to cycle:
… => (load "byte-opt.el") => (macroexpand-all …
…
I don't know if these are actionable but they are designated as warnings,
and displayed with the same compilation-enter-directory-face
as these unimportant messages:
Pure-hashed: 16071 strings, 4220 vectors, 41688 conses, 3769 bytecodes, 267 others
make[1]: Entering directory
> My personal advice is to read carefully every line displayed by the
> build process, and not limit yourself to warnings. Messages that
> aren't supposed to appear during a normal build should be discovered
> regardless of whether they are warnings/errors or not.
It's not realistic to read thousands of lines from every compilation.
It should be enough just to look at the compilation's mode line
to see the total number of errors (in red color), warnings (orange),
and the number of informational messages (in green color).
So if you think such messages are not warnings then
such messages should be detected as informational messages
displayed with the green color that has the corresponding
indicator on the mode line and at the end of the compilation output.
etc/compilation.txt demonstrates the supported syntax:
foo.c:8:I: message
foo.c:8.23: note: message
foo.c:8.23: info: message
foo.c:8:23:information: message
foo.c:8.23-45: Informational: message
Another problem is that such syntax requires as least a file name
and a line number that is not always available. A workaround is
to display a fake name and number.
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-07-30 17:54 ` Juri Linkov
@ 2021-07-30 18:26 ` Eli Zaretskii
2021-07-30 22:08 ` Stefan Monnier
1 sibling, 0 replies; 24+ messages in thread
From: Eli Zaretskii @ 2021-07-30 18:26 UTC (permalink / raw)
To: Juri Linkov; +Cc: larsi, monnier, leungbk, emacs-devel
> From: Juri Linkov <juri@linkov.net>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, Stefan Monnier
> <monnier@iro.umontreal.ca>, leungbk@mailfence.com, emacs-devel@gnu.org
> Date: Fri, 30 Jul 2021 20:54:11 +0300
>
> I don't know if these are actionable but they are designated as warnings,
> and displayed with the same compilation-enter-directory-face
> as these unimportant messages:
>
> Pure-hashed: 16071 strings, 4220 vectors, 41688 conses, 3769 bytecodes, 267 others
The above might look unimportant to you, but with some wildly
different numbers shown it certainly should be noticed and reported.
> > My personal advice is to read carefully every line displayed by the
> > build process, and not limit yourself to warnings. Messages that
> > aren't supposed to appear during a normal build should be discovered
> > regardless of whether they are warnings/errors or not.
>
> It's not realistic to read thousands of lines from every compilation.
Nevertheless, that's my advice. If you are sensitive to unusual
messages during the build, you will catch issues sooner rather than
later. I hope you and others _will_ notice unusual messages, because
we then can find and react to problems much faster.
> Another problem is that such syntax requires as least a file name
> and a line number that is not always available. A workaround is
> to display a fake name and number.
Some messages don't have any pertinent file name/line number
information attached to them. That doesn't mean they are unimportant.
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-07-30 17:54 ` Juri Linkov
2021-07-30 18:26 ` Eli Zaretskii
@ 2021-07-30 22:08 ` Stefan Monnier
1 sibling, 0 replies; 24+ messages in thread
From: Stefan Monnier @ 2021-07-30 22:08 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, Lars Ingebrigtsen, leungbk, emacs-devel
Juri Linkov [2021-07-30 20:54:11] wrote:
> For example, today's compilation displayed as lot of such lines:
>
> Warning: Eager macro-expansion skipped due to cycle:
> … => (load "byte-opt.el") => (macroexpand-all …
> Warning: Eager macro-expansion skipped due to cycle:
> … => (load "byte-opt.el") => (macroexpand-all …
> …
These usually reflect bugs, but we can't conveniently pin them on
a particular file (they're usually due to a cycle between macros and
functions in several files), so I don't think using the standard
"<FILE>:<FOO>" syntax for warnings would be all that useful, but it
wouldn't make things worse either, so a "<FILE>:0:" prefix sounds like
a good idea (where <FILE> would presumably be the file we're eagerly
macroexpanding).
Sometimes they're highly dependent on specific ordering of compilation
of files, but if you can reproduce them reliably, then please report
them so we can try and fix them.
Stefan
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-07-30 5:43 ` Eli Zaretskii
2021-07-30 10:55 ` Lars Ingebrigtsen
2021-07-30 17:54 ` Juri Linkov
@ 2021-07-30 22:03 ` Stefan Monnier
2021-08-01 8:32 ` Juri Linkov
2 siblings, 1 reply; 24+ messages in thread
From: Stefan Monnier @ 2021-07-30 22:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: Lars Ingebrigtsen, juri, leungbk, emacs-devel
> Stefan, any comments/suggestions?
It definitely makes sense to use the "FILE:TXT" warning format for that
warning (after all, we do have the file name). I don't think we can
usefully put a line number info there, but a 0 should do the trick.
Note also that these aren't compilation warnings, instead they're
emitted by the `autoload.el` code.
The effect of those problems is quite minor: it affects the info we
compute which maps command/var prefixes to files (so that `C-h o`
completion can automatically load files to find a var/function).
I think we should aim to fix those warnings because they reflect a bad
namespace behavior on the part of the file, but it's not
super important.
Stefan
^ permalink raw reply [flat|nested] 24+ messages in thread* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-07-30 22:03 ` Stefan Monnier
@ 2021-08-01 8:32 ` Juri Linkov
2021-08-01 10:42 ` Lars Ingebrigtsen
2021-08-01 14:28 ` Stefan Monnier
0 siblings, 2 replies; 24+ messages in thread
From: Juri Linkov @ 2021-08-01 8:32 UTC (permalink / raw)
To: Stefan Monnier; +Cc: Eli Zaretskii, Lars Ingebrigtsen, leungbk, emacs-devel
> It definitely makes sense to use the "FILE:TXT" warning format for that
> warning (after all, we do have the file name). I don't think we can
> usefully put a line number info there, but a 0 should do the trick.
At least, this patch can highlight them as informational messages
(according to syntax in etc/compilation.txt) that also increments
their number displayed with green on the mode-line:
diff --git a/lisp/emacs-lisp/autoload.el b/lisp/emacs-lisp/autoload.el
index 9d1ae70597..5238e985f2 100644
--- a/lisp/emacs-lisp/autoload.el
+++ b/lisp/emacs-lisp/autoload.el
@@ -626,8 +626,8 @@ autoload--make-defs-autoload
(radix-tree-iter-mappings
(cdr x) (lambda (s _)
(push (concat prefix s) dropped)))
- (message "Not registering prefix \"%s\" from %s. Affects: %S"
- prefix file dropped)
+ (message "%s:0:I: Not registering prefix \"%s\" from %s. Affects: %S"
+ file prefix file dropped)
nil))))
prefixes)))
`(register-definition-prefixes ,file ',(sort (delq nil strings)
^ permalink raw reply related [flat|nested] 24+ messages in thread* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-08-01 8:32 ` Juri Linkov
@ 2021-08-01 10:42 ` Lars Ingebrigtsen
2021-08-01 14:28 ` Stefan Monnier
1 sibling, 0 replies; 24+ messages in thread
From: Lars Ingebrigtsen @ 2021-08-01 10:42 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, Stefan Monnier, leungbk, emacs-devel
Juri Linkov <juri@linkov.net> writes:
> At least, this patch can highlight them as informational messages
> (according to syntax in etc/compilation.txt) that also increments
> their number displayed with green on the mode-line:
Looks like an improvement to me.
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
^ permalink raw reply [flat|nested] 24+ messages in thread
* Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
2021-08-01 8:32 ` Juri Linkov
2021-08-01 10:42 ` Lars Ingebrigtsen
@ 2021-08-01 14:28 ` Stefan Monnier
1 sibling, 0 replies; 24+ messages in thread
From: Stefan Monnier @ 2021-08-01 14:28 UTC (permalink / raw)
To: Juri Linkov; +Cc: Eli Zaretskii, Lars Ingebrigtsen, leungbk, emacs-devel
> - (message "Not registering prefix \"%s\" from %s. Affects: %S"
> - prefix file dropped)
> + (message "%s:0:I: Not registering prefix \"%s\" from %s. Affects: %S"
> + file prefix file dropped)
Sounds good, tho I think it should be labeled as a warning rather than
purely informational (also we can drop the "from %s" since it's
redundant).
Stefan
^ permalink raw reply [flat|nested] 24+ messages in thread