On 2022-11-03, Vagrant Cascadian wrote:
> On 2022-11-03, Ludovic Courtès wrote:
>> Vagrant Cascadian <vagrant@debian.org> skribis:
>>
>>> --- a/guix/lint.scm
>>> +++ b/guix/lint.scm
>>> @@ -313,7 +313,8 @@ (define (tests-explicitly-enabled?)
>>>        '()))
>>>  
>>>  (define (properly-starts-sentence? s)
>>> -  (string-match "^[(\"'`[:upper:][:digit:]]" s))
>>> +  (string-match "^[(\"'`[:upper:][:digit:]]"
>>> +                (string-replace-substring s "@code{" "")))
>>
>> An identifier in @code or file name in @file may legitimately start with
>> a lower-case letter so I don’t think we should try to prevent that.
>>
>> However, maybe we could change the regexp above to something that
>> accepts @ or some other non-letter character at the start?
>
> Great suggestion, as it is simpler, easier to read, and actually covers
> more false positives! Updated patch attached!
>
> I think there was only one case fixed by the @code{} check for the
> synopsis length check, and I don't see any obvious other @*{} checks
> that would currently improve anything, though it would be ideal to make
> it more future-proof just in case... though I think my attempt at that
> would be awfully ugly, help from others would be welcome!

Well, ugly is what I have... Found two packages affected by @acronym.

Also realized that it should leave the {} in the length-matching, as
they are typically replaced by other characters when rendered.


> That said, I think this resolves 52 false positives with guix lint (~10%
> of the 536 synopsis/description issues currently).

Think with this applied there are 54 false positives fixed.

live well,
  vagrant