Fw: Re: _arguments: repeated option with multiple optargs

Fw: Re: _arguments: repeated option with multiple optargs

[Peter Stephenson]

I meant to send this to the list, not just to Roman...

Roman Neuhauser <neuhauser@sigpipe.cz> wrote:
> _arguments -s : '*-r=::->file:*:::->test'
> 
> does exactly what the manual say it does, IOW all the remaining words on
> the line are to be completed as described by the action. That's not what
> I want, though: the whole (-r file 1*test) can be repeated, and I'd like
> it to offer also -r.
> 
> Can _arguments do this for me somehow, or is this up to me?

I haven't much experience with multiple arguments, but it looks from the
manual page like you ought to be able to tell it that it should stop at the
next argument that starts with -r; which isn't logically correct, but ought
to do the trick:

              Each optarg following an optspec must take one of the  following
              forms:
...
              :*pattern:message:action
              :*pattern::message:action
              :*pattern:::message:action
                     This  describes multiple arguments.  Only the last optarg
                     for an option taking multiple arguments may be  given  in
                     this  form.  If the pattern is empty (i.e., :*:), all the
                     remaining words on  the  line  are  to  be  completed  as
                     described by the action; otherwise, all the words up to a
                     word matching the pattern are to be completed  using  the
                     action.

(Typically, it never actually defines what it means by an "optarg", but it
obviously means everything from the first colon onwards.)  It's quite
possible this isn't well tested.  The guy who wrote _arguments (and most of
the rest of the completion system) has been in hiding for several years.

However, I don't think _arguments is very good at this sort of complexity.
Somewhere there's a parser that implements a finite state machine for
completion arguments, but currently no one in the entire world understands
that.  It could do with resurrecting in a more friendly fashion.

When things get complicated, I tend to use the *::<stuff>:<morestuff> form
of argument which restricts the command line to the arguments I'm looking
at and take it from there.  It usually means a call to an additional
_arguments (in Unix/Command/_perforce, for example, which isn't a
particularly simple example).  However, I'm really thinking of the case
where you have something like <cmd> <subcmd> <subcmd-specific-args>, which
is a little different from what you've got.

-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


-- 
Peter Stephenson <pws@csr.com>                  Software Engineer
CSR PLC, Churchill House, Cambridge Business Park, Cowley Road
Cambridge, CB4 0WZ, UK                          Tel: +44 (0)1223 692070


To access the latest news from CSR copy this link into a web browser:  http://www.csr.com/email_sig.php

Re: Fw: Re: _arguments: repeated option with multiple optargs

[Bart Schaefer]

On Sep 20, 10:06am, Peter Stephenson wrote:
} Subject: Fw: Re: _arguments: repeated option with multiple optargs
}
}               Each optarg following an optspec must take one of the  following
}               forms:
} ...
} 
} (Typically, it never actually defines what it means by an "optarg", but it
} obviously means everything from the first colon onwards.)

Strange, I was sure it used to at least reference that in the syntax
synopsis.  I.e., that it used to say

    optspec
    optspec:optarg

where now it says

    optspec
    optspec:...

However, the colon is considered part of the optarg, and it doesn't look
very nice to write

    optspec
    optspecoptarg

so this probably got edited a long time ago and the lost forward reference
was just never fixed.