bug#57673: [PATCH] Parse --help messages for pcomplete

[Augusto Stoffel]

On Wed, 14 Sep 2022 at 21:48, Lars Ingebrigtsen wrote:

> Augusto Stoffel <arstoffel@gmail.com> writes:
>
>> I've attached a patch to be applied (and squashed) on top of what I sent
>> previously.  Let me know if this is inconvenient and I'll send the whole
>> thing.
>
> I'd prefer the whole thing in one patch.

Voilà.

0001-pcomplete-Generate-completions-from-help-messages.patch
Description: Text Data

>
> [...]
>
>> +               ("start"
>> +                (pcomplete-here
>> +                 (pcmpl-linux--systemd-units context "--state" 
>> "inactive,failed")))
>> +               ((or "restart" "stop")
>> +                (pcomplete-here
>> +                 (pcmpl-linux--systemd-units context "--state" "active")))
>
> But...  subcmd isn't used here in the new lines, either, so does that
> really fix the warning?

`subcmd' was always there, textually, in the `(pcase subcmd' right above
that.  But in the previous version of the code it disappeared during
macro expansion because it was not compared against anything in the
pcase patterns.

Very neat sanity check, indeed (but I did what I did on purpose because
I wanted to leave the function in an easier shape for future
refinements).

>> Hum, I don't know how to fix this.  The long line is the function
>> signature, which is created mechanically by cl-defun and displays all
>> the default values of the keyword arguments.
>>
>> The formatting is horrible:
>>
>>     (pcomplete-from-help COMMAND &rest ARGS &key (MARGIN (rx bol (+ " ")))
>>     (ARGUMENT (rx "-" (+ (any "-" alnum)) (32 "="))) (METAVAR (rx (32 " ")
>>     (or (+ (any alnum "_-")) (seq "[" (+? nonl) "]") (seq "<" (+? nonl)
>>     ">") (seq "{" (+? nonl) "}")))) (SEPARATOR (rx ", " symbol-start))
>>     (DESCRIPTION (rx (* nonl) (* "\n" (>= 9 " ") (* nonl)))) NARROW-START
>>     NARROW-END)
>>
>> But the information is good to have, because you need to know what these
>> regexps are in order to use the function.
>
> Oh, yeah, that's pretty bad...  we should probably fix that in the
> cl-defun macro, I guess, so this doesn't have to be fixed in this patch.

All right, thanks.