Re: Nested completion of arguments

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Andrej Borsenkow wrote:

> Sorry, I could not follow recent changes closely, so may be this question is
> trivial.
> 
> I'd like to have completion for mount and share commands. On our system (SVR4
> based) the general syntax of mount is
> 
> mount [-F FSType] [-Vr] [-o specific_options] special mount_point
> 
> where specific_options are in the form
> 
> option[=value],...
> 
> The same is for share, 'course.
> 
> The question is, is it currently possible to complete this `specific_options'
> part (with autoremoved `,' and all this completion sugar). Note, that values of
> options may itself be completed as list; the trivial example is
> 
> share -o root=host1:host2
> 
> Also, the possible values for specific options depends on FSType.
> 
> I don't ask for a complete function :-) but just for a hint what can be used.
> 
> Note, that this form is officially blessed by UNIX specs as getsubopt()
> function. So, it may be nice to have a general way to parse such option string.
> (Not that I can name other commands that use it offhead).

The `actions' that can be given to `_arguments' are based on the ones
that were possible with `_long_options' -- plus a few new nice things.
So, yes, you could use `_arguments' in `_mount' and then make it
either call another function to complete the sub-options (which, of
course, is quite trivial to write, as you know) or -- in the way
recently suggested make it set some parameter and test that in the
calling function to complete the options there. We don't have support
to describe such sub-options. And I think, this should probably be
done with a separate function, at least don't see any advantage in
adding this to `_arguments'.

We don't have support to get at options found on the command line,
yet, only at the normal arguments. But this could be added. One
question is, how we store this information. It would be nice if we
could use an association mapping options to their arguments, but that
won't work because we would need to store arrays in an association
then. Hm, we could use an association mapping options to names of
(temporary) arrays holding the arguments. But maybe someone has a
better idea?
Also, currently we only parse the command line up to the word the
cursor is on. With that any options after that wouldn't appear, so
this should probably be changed (and make things a bit slower).

Btw, if we start using `_arguments' with the parameter-setting thing
we would have to set `compstate[restore]=""' in it to make sure the
calling function gets the changed special parameters when completing
e.g. directly after an option. We could make this optional. We could
make this optional on a per-action basis. This may then be a reason to 
add a action syntax for such `states'.
We should also make the `line' array be available in the calling
function, then.

And while I'm at it, I forgot to answer one of Tanakas comments: I
also made the suggestion about the state machines so that we could
cram everything for a suite of commands (or monster-commands such as
cvs) into one function while still making them readable (with a 
`case ... esac'). After all, people want us to reduce the number of
functions (which I can understand).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx