unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Juri Linkov <juri@linkov.net>
To: Eli Zaretskii <eliz@gnu.org>
Cc: Lars Ingebrigtsen <larsi@gnus.org>,
	Stefan Monnier <monnier@iro.umontreal.ca>,
	leungbk@mailfence.com, emacs-devel@gnu.org
Subject: Re: master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode
Date: Fri, 30 Jul 2021 20:54:11 +0300	[thread overview]
Message-ID: <87r1ffit6k.fsf@mail.linkov.net> (raw)
In-Reply-To: <837dh8s6fj.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 30 Jul 2021 08:43:12 +0300")

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



  parent reply	other threads:[~2021-07-30 17:54 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20210727211521.15408.98852@vcs0.savannah.gnu.org>
     [not found] ` <20210727211523.AE6F72065F@vcs0.savannah.gnu.org>
2021-07-28 15:40   ` master cfcf42f 2/2: Ensure that gud commands for non-GDB debuggers are handled by repeat-mode Lars Ingebrigtsen
2021-07-28 16:24     ` Juri Linkov
2021-07-28 16:35       ` Lars Ingebrigtsen
2021-07-28 16:49         ` Juri Linkov
2021-07-29 20:13           ` Lars Ingebrigtsen
2021-07-29 22:43             ` Juri Linkov
2021-07-30 10:53               ` Lars Ingebrigtsen
2021-07-30 17:51                 ` Juri Linkov
2021-07-30 18:13                   ` Lars Ingebrigtsen
2021-07-30  5:43             ` Eli Zaretskii
2021-07-30 10:55               ` Lars Ingebrigtsen
2021-07-30 11:03                 ` Eli Zaretskii
2021-07-30 11:16                   ` Lars Ingebrigtsen
2021-07-30 12:13                     ` Eli Zaretskii
2021-07-30 12:20                       ` Lars Ingebrigtsen
2021-07-30 13:22                         ` Eli Zaretskii
2021-07-30 14:39                           ` Lars Ingebrigtsen
2021-07-30 17:54               ` Juri Linkov [this message]
2021-07-30 18:26                 ` Eli Zaretskii
2021-07-30 22:08                 ` Stefan Monnier
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=87r1ffit6k.fsf@mail.linkov.net \
    --to=juri@linkov.net \
    --cc=eliz@gnu.org \
    --cc=emacs-devel@gnu.org \
    --cc=larsi@gnus.org \
    --cc=leungbk@mailfence.com \
    --cc=monnier@iro.umontreal.ca \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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).