Re: [PATCH 2/2] chainlint: reduce annotation noise-factor

From: Eric Sunshine <sunshine@sunshineco.com>
Date: Aug 29, 2024, 18:28 UTC
Message-ID: <CAPig+cTTXmaAjJrOOSKKDKvMAE+yD9wfoYii5C21jGpq=sqtyA@mail.gmail.com>
In-Reply-To: <ZtBHecRkFQkSAF6C@tanuki>

On Thu, Aug 29, 2024 at 6:03 AM Patrick Steinhardt <ps@pks.im> wrote:

Show 24 quoted lines

> On Thu, Aug 29, 2024 at 05:16:25AM -0400, Eric Sunshine wrote:
> > 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.
>
> Okay, now the "ERR" prefix becomes a bit more important because we drop
> the other punctuation. I'm still not much of a fan of it, though. Makes
> me wonder whether we want to take a clue from how compilers nowadays
> format this, e.g. by using "pointers".
>
> So this:
>     7   fish |
>     8   cow ?!AMP?!
>
> Would become this:
>     t/chainlint/pipe.actual:8: error: expected ampersands (&&)
>     7   fish |
>     8   cow
>             ^
>
> While this would be neat, I guess it would also be way more work than
> the current series you have posted. And whether that work is ultimately
> really worth it may be another question. Probably not.

Interestingly, I'm not always a fan of the sort of compiler output you suggest since I often have more difficulty interpreting the output and locating the actual problem[*] than if the annotation was merely inline, sitting immediately next to the problem itself.

Also, the vast majority of the time, chainlint will be flagging a missing "&&" at the end of line, so with the inline annotation, it's very easy to see (especially when colored) exactly where the problem is at a glance.

Hence, the cost of implementing "^" doesn't feel particularly worthwhile (and, with my limited Git time these days, I'm unlikely to do so).

[*] This is especially so when dealing with foreign code which is wider than my 80-column terminal or 80-column editor window, in which the source text and the "^" may wrap over multiple lines.