Re: PATCH: Re: sudo completion problem

[Tanaka Akira <akr@xxxxxxxx>]

In article <000601bfb599$a9219f80$21c9ca95@xxxxxxxxxxxxxx>,
  "Andrej Borsenkow" <Andrej.Borsenkow@xxxxxxxxxxxxxx> writes:

> So, the question is - how useful would it be to allow "named,
> structured, ..." arguments? The point is, description vs. shell code.
> Basically, be able to treat arguments in almost the same way as
> options - with some separator in between. In this case, we could still
> use _arguments for find - actually, it does it quite well currently, and
> it is a pity to reinvent the wheel.

Although I think (-) is good extension, I agree that there are
commands which has too complex argument parsing routine to handle by
_arguments.  And it is true that writing dedicated handling routine as
shell function is too difficult in general.

We need intermediate solution for a completion function of such
commands: more powerful than _arguments and easier than shell
function.  But more difficult than _arguments, maybe.

My idea is already implemented: _regex_arguments.  Although currently
there are only three completion functions - _apt, _xwit and _xset -
which use _regex_arguments because it cannot use _arguments,  I think
there are more completion  functions which can be written bit more
simple if _regex_arguments is used.  Maybe, _xauth (and _cvs?).

> I understand, that this is hierarchical structure that probably cannot
> be handled with one single table ... but, just as idea, imagine that
> action for `update' argument simply points to subarguments description
> ... or something like this ... this may be more readable than shell
> functions. May be not. But it is easier in cases, where we need several
> versions for different plattforms.

In _regex_arguments, a arguments of commands are described as regex
like notation.  Of course, it can handle hierarchical one.

> Then I realised, that reverse situation exists with options - there is
> no way to describe options without - prefix. Consider dd or tar ("tar"
> not "GNU tar" :-), BSD ps ... In case of dd we have only options; in
> case of tar ot ps, the first word consists of single letter options with
> possible arguments in next words in order. There is no way to describe
> both case with _arguments (unless I'm mistaken).

_regex_arguments doesn't handle `-' or `+' specially.

> And I'd like repeat once more - currently, when _arguments is using
> lexical structure to describe semantic, it is hard to add something. If
> we had flags ... (not suggesting breaking compatibility - but just for
> future use).

_regex_arguments handle only parsing of arguments.  So other stuff
handled by _arguments such as descriptions, exclusive options must be
implemented by completion function writer.  It's bit hard task but we
can implement special feature easily.
-- 
Tanaka Akira