Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Lars Ingebrigtsen]

This leads to the following compilation warning:

Not registering prefix "gu" from gud.  Affects: ("guiler-repeat-map" "gud-val" "gud-last-frame" "gud-last-last-frame" "gud-last-speedbar-stackframe" "gud-query-cmdline" "gud-xdb-history" "gud-xdb-directories"

(etc etc).

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Juri Linkov]

> This leads to the following compilation warning:
>
> Not registering prefix "gu" from gud.  Affects: ("guiler-repeat-map"
> "gud-val" "gud-last-frame" "gud-last-last-frame"
> "gud-last-speedbar-stackframe" "gud-query-cmdline" "gud-xdb-history"
> "gud-xdb-directories"

Why this compilation warning is not highlighted with red color
as other warnings?

> (etc etc).

This should be fixed now.

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> This leads to the following compilation warning:
>>
>> Not registering prefix "gu" from gud.  Affects: ("guiler-repeat-map"
>> "gud-val" "gud-last-frame" "gud-last-last-frame"
>> "gud-last-speedbar-stackframe" "gud-query-cmdline" "gud-xdb-history"
>> "gud-xdb-directories"
>
> Why this compilation warning is not highlighted with red color
> as other warnings?

Yeah, the warning should probably be rewritten to start with "Warning: "
or something?

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Juri Linkov]

>>> Not registering prefix "gu" from gud.  Affects: ("guiler-repeat-map"
>>
>> Why this compilation warning is not highlighted with red color
>> as other warnings?
>
> Yeah, the warning should probably be rewritten to start with "Warning: "
> or something?

It's displayed as a warning only when prefixed with "0:0:0: Warning: ".

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>> Yeah, the warning should probably be rewritten to start with "Warning: "
>> or something?
>
> It's displayed as a warning only when prefixed with "0:0:0: Warning: ".

Right, so we could change this message to say that?

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Juri Linkov]

>>> Yeah, the warning should probably be rewritten to start with "Warning: "
>>> or something?
>>
>> It's displayed as a warning only when prefixed with "0:0:0: Warning: ".
>
> Right, so we could change this message to say that?

This is the same old problem:
https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg01016.html

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Date: Thu, 29 Jul 2021 22:13:40 +0200
> Cc: Brian Leung <leungbk@mailfence.com>, emacs-devel@gnu.org
> 
> Juri Linkov <juri@linkov.net> writes:
> 
> >> Yeah, the warning should probably be rewritten to start with "Warning: "
> >> or something?
> >
> > It's displayed as a warning only when prefixed with "0:0:0: Warning: ".
> 
> Right, so we could change this message to say that?

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

Stefan, any comments/suggestions?

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.

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

>>> It's displayed as a warning only when prefixed with "0:0:0: Warning: ".
>>
>> Right, so we could change this message to say that?
>
> This is the same old problem:
> https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg01016.html

I didn't read the entire thread there, but that one message seemed to be
in violent agreement?

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Lars Ingebrigtsen]

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Eli Zaretskii]

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Lars Ingebrigtsen]

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Eli Zaretskii]

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Lars Ingebrigtsen]

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Eli Zaretskii]

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Lars Ingebrigtsen]

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Juri Linkov]

> Juri Linkov <juri@linkov.net> writes:
>
>>>> It's displayed as a warning only when prefixed with "0:0:0: Warning: ".
>>>
>>> Right, so we could change this message to say that?
>>
>> This is the same old problem:
>> https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg01016.html
>
> I didn't read the entire thread there, but that one message seemed to be
> in violent agreement?

The problem is that such fake numbers as "0:0:0:Warning:"
make no sense.

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Juri Linkov]

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Lars Ingebrigtsen]

Juri Linkov <juri@linkov.net> writes:

> The problem is that such fake numbers as "0:0:0:Warning:"
> make no sense.

We know the file name, I think?  So the first zero can go.  We do issue
warnings where we don't know the line/column numbers for some stuff, and
0:0 would be as sensible as anything else here...

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Eli Zaretskii]

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Stefan Monnier]

> 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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Stefan Monnier]

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Juri Linkov]

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Lars Ingebrigtsen]

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

Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode

[Stefan Monnier]

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