From: Junio C Hamano <gitster@pobox.com>
To: Eric Sunshine <ericsunshine@charter.net>
Cc: git@vger.kernel.org, Jeff King <peff@peff.net>,
Eric Sunshine <sunshine@sunshineco.com>
Subject: Re: [PATCH 2/2] chainlint: reduce annotation noise-factor
Date: Thu, 29 Aug 2024 08:55:17 -0700 [thread overview]
Message-ID: <xmqqv7zjwcgq.fsf@gitster.g> (raw)
In-Reply-To: <20240829091625.41297-3-ericsunshine@charter.net> (Eric Sunshine's message of "Thu, 29 Aug 2024 05:16:25 -0400")
Eric Sunshine <ericsunshine@charter.net> writes:
> From: Eric Sunshine <sunshine@sunshineco.com>
>
> When chainlint detects a problem in a test definition, it highlights the
> offending code with an "?!ERR ...?!" annotation. The rather curious "?!"
> delimiter was chosen to draw the reader's attention to the problem area.
>
> Later, chainlint learned to color its output when sent to a terminal.
> Problem annotations are colored with a red background which stands out
> well from surrounding text, thus easily draws the reader's attention. As
> such, the additional "?!" decoration became superfluous (when output is
> colored), however the decoration was retained since it serves as a good
> needle when using the terminal's search feature to "jump" to the next
> problem.
>
> Nevertheless, the "?!" decoration is noisy and ugly and makes it
> unnecessarily difficult for the reader to pluck the problem description
> from the annotation. For instance, it is easier to see at a glance what
> the problem is in:
>
> ERR missing '&&'
>
> than in the noisier:
>
> ?!ERR missing '&&'?!
>
> Therefore drop the "!?" decoration when output is colored (but retain it
> otherwise).
Wait. That does not qualify "Therefore".
We talked about a "good needle" and then complained how ugly the
string that was happened to be chosen as good needle is. That is
not enough to explain why it is justified to "lose" the needle. The
only thing you justified is to move away from the ugly pattern, as a
typical "terminal's search feature" does not give us an easy way to
"jump to the next text painted yellow".
> Note that the preceding change gave all problem annotations a uniform
> "ERR" prefix which serves as a reasonably suitable replacement needle
> when searching in a terminal, so loss of "?!" in the output should not
> be overly problematic.
Drop this separate paragraph, promote its contents up from "Note"
status and as a proper part of the previous sentence in its rewrite,
something like:
Since the errors are all uniformly prefixed with "ERR", which
can be used as the "good needle" instead, lose the "!?"
decoration when output is colored.
to replace "Therefore" and everything that follow.
> @@ -663,7 +666,7 @@ sub check_test {
> $checked =~ s/^\d+ \n//;
> $checked =~ s/(\s) \?!/$1?!/mg;
> $checked =~ s/\?! (\s)/?!$1/mg;
> - $checked =~ s/(\?![^?]+\?!)/$c->{rev}$c->{red}$1$c->{reset}/mg;
> + $checked =~ s/\?!([^?]+)\?!/$erropen$1$errclose/mg;
Hmph. With $erropen and $errclose, I was hoping that we can shed
the reliance on the "?!" mark even internally. This is especially
true that in the early part of this sub, the problem description was
very much structured piece of data, not something the consuming code
need to pick out of an already formatted text like this, risking to
get confused by the payload (i.e. the text that came from the
problematic test script inside "substr($body, $start, $pos-$start)"
may contain anything, including "?!", right?).
> $checked =~ s/^\d+/$c->{dim}$&$c->{reset}/mg;
> $checked .= "\n" unless $checked =~ /\n$/;
> push(@{$self->{output}}, "$c->{blue}# chainlint: $title$c->{reset}\n$checked");
> @@ -805,9 +808,9 @@ sub check_script {
> my $c = fd_colors(1);
> my $s = join('', @{$parser->{output}});
> $emit->("$c->{bold}$c->{blue}# chainlint: $path$c->{reset}\n" . $s);
> - $nerrs += () = $s =~ /\?![^?]+\?!/g;
> }
> $ntests += $parser->{ntests};
> + $nerrs += $parser->{nerrs};
> }
> return [$id, $nscripts, $ntests, $nerrs];
> }
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index 54247604cb..b652cb98cd 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -1606,7 +1606,7 @@ if test "${GIT_TEST_CHAIN_LINT:-1}" != 0 &&
> test "${GIT_TEST_EXT_CHAIN_LINT:-1}" != 0
> then
> "$PERL_PATH" "$TEST_DIRECTORY/chainlint.pl" "$0" ||
> - BUG "lint error (see '?!...!? annotations above)"
> + BUG "lint error (see 'ERR' annotations above)"
> fi
>
> # Last-minute variable setup
Overall the two patches looked great.
Thanks.
next prev parent reply other threads:[~2024-08-29 15:55 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-08-29 9:16 [PATCH 0/2] make chainlint output more newcomer-friendly Eric Sunshine
2024-08-29 9:16 ` [PATCH 1/2] chainlint: make error messages self-explanatory Eric Sunshine
2024-08-29 10:03 ` Patrick Steinhardt
2024-08-29 17:07 ` Jeff King
2024-08-29 18:10 ` Eric Sunshine
2024-08-29 18:01 ` Eric Sunshine
2024-08-29 15:39 ` Junio C Hamano
2024-08-29 22:04 ` Eric Sunshine
2024-08-30 18:41 ` Junio C Hamano
2024-08-29 9:16 ` [PATCH 2/2] chainlint: reduce annotation noise-factor Eric Sunshine
2024-08-29 10:03 ` Patrick Steinhardt
2024-08-29 17:10 ` Jeff King
2024-08-29 18:37 ` Eric Sunshine
2024-08-29 18:28 ` Eric Sunshine
2024-08-29 15:55 ` Junio C Hamano [this message]
2024-08-30 23:30 ` Eric Sunshine
2024-08-30 23:51 ` Junio C Hamano
2024-09-10 4:10 ` [PATCH v2 0/3] make chainlint output more newcomer-friendly Eric Sunshine
2024-09-10 4:10 ` [PATCH v2 1/3] chainlint: don't be fooled by "?!...?!" in test body Eric Sunshine
2024-09-10 16:48 ` Junio C Hamano
2024-09-10 4:10 ` [PATCH v2 2/3] chainlint: make error messages self-explanatory Eric Sunshine
2024-09-10 7:48 ` Patrick Steinhardt
2024-09-10 4:10 ` [PATCH v2 3/3] chainlint: reduce annotation noise-factor Eric Sunshine
2024-09-10 7:48 ` Patrick Steinhardt
2024-09-10 8:14 ` Eric Sunshine
2024-09-10 15:42 ` Junio C Hamano
2024-09-10 22:17 ` Eric Sunshine
2024-09-10 6:44 ` [PATCH v2 0/3] make chainlint output more newcomer-friendly Jeff King
2024-09-10 17:31 ` Junio C Hamano
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=xmqqv7zjwcgq.fsf@gitster.g \
--to=gitster@pobox.com \
--cc=ericsunshine@charter.net \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
--cc=sunshine@sunshineco.com \
/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.
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 NNTP newsgroup(s).