Re: guix lint false positives and RFC patch

[Vagrant Cascadian <vagrant@debian.org>]

[-- Attachment #1: Type: text/plain, Size: 2333 bytes --]

On 2023-01-27, Simon Tournier wrote:
> On sam., 12 nov. 2022 at 17:54, Vagrant Cascadian <vagrant@debian.org> wrote:
>> On 2022-11-05, Ludovic Courtès wrote:
>>> Vagrant Cascadian <vagrant@debian.org> skribis:
>>>> From bfa13fdd3616839883e50efbbc05fb132610ce67 Mon Sep 17 00:00:00 2001
>>>> From: Vagrant Cascadian <vagrant@debian.org>
>>>> Date: Wed, 2 Nov 2022 19:56:12 -0700
>>>> Subject: [PATCH 01/12] guix: lint: Exclude some "@" symbols from various
>>>>  checks.
>>>>
>>>> The visual representation of "@code{}" or similar in the description and
>>>> synopsis do not include the string, so exclude it from checks to avoid false
>>>> positives.
>>>>
>>>> FIXME handle @command, @file, @acronym, etc.
>>>>
>>>> * guix/linx.scm (properly-starts-sentence): Exclude leading "@".
>>>>   (check-synopsis-length): Exclude "@code" and "@acronym".
>>>
>>> LGTM!  Bonus points for a test in ‘tests/lint.scm’.  :-)
>>
>> No bonus points for me just yet...
>
> [...]
>
>> What is failing to match what here?
>
> Well, almost done but not merged, right?
>
> Still an issue this ’match’?

Thanks for bringing this back up to the surface! I struggled with it a
bit and honestly do not remember where I last left it... I think I made
some further progress... and then hit a new blocker and the sun went
down and slept on it ... and never got back to it.

So I was definitely stuck writing a test. From vague memory, I think
once I figured out how to have the test not fail wit guile complaining
inscrutibly... it did not effectively test the thing it was supposed to.

The other thing I remember being caught up on, which was not a
deal-breaker, per se, was hoping for a way to loop through a bunch of
@SOMETHING things ... I was not happy with:

+    (if (>= (string-length (string-replace-substring
+                            (string-replace-substring synopsis "@acronym" "")
+                            "@code" ""))
+                           80)

And then adding @command, @file, @acronym, etc. ... using increasingly
nested levels string-replace-substring would eventually become difficult
to read and surely there is a better way!

I might be able to take another look at this in february, but I would
welcome help wrapping this up regardless!

live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]