Felix,
> Please let me pick your brain. My current solution is to instantiate
> tags as they are issued, but they are a bit cumbersome to use.
I cannot recall I had a more concise approach beyond a bunch of
dirty "tag_with_filename"-like helpers/wrappers. Just to be clear,
this was very much a
Hi Chris,
On Sat, Dec 7, 2019 at 2:57 PM Chris Lamb wrote:
>
> If it helps, my plan was that we call "tag" with many more arguments
> which all end up in said metadata, but each tag had a "to_string"
> method (or similar) that would render it into the existing flat,
> plaintext string... both
Hi Felix,
> Mentioning source files and line numbers, on the other hand, requires
> a retooling in most checks.
Don't worry, I think we are talking about exactly the same thing.
I have a (very old) branch that starts to do this but I'm sure you
will get around to this before me though.
If it
Hi Chris,
On Sat, Dec 7, 2019 at 12:43 PM Chris Lamb wrote:
>
> (FYI there's a wishlist bug somewhere requesting machine-readable
> output in a format such as JSON/Yaml/etc. where the fields are
> consistent and named reliably)
>From my perspective it is a different, although perhaps more
Hi Jelmer et al.,
> That said, I think it would be great to have this feature in lintian -
> easily being able to jump to the relevant line in an editor would be
> very useful.
(FYI there's a wishlist bug somewhere requesting machine-readable
output in a format such as JSON/Yaml/etc. where the
Hi Felix,
On Sat, Dec 07, 2019 at 06:03:15AM -0800, Felix Lechner wrote:
> Would more reporting detail, as outlined in this bug, be useful to
> lintian-brush or to D-Janitor?
Not directly, I think the lintian-info field in the lintian output is
more useful for the janitor.
That said, I think it
Hi Jelmer,
Would more reporting detail, as outlined in this bug, be useful to
lintian-brush or to D-Janitor?
Kind regards
Felix Lechner
7 matches
Mail list logo
