Re: PATCH: Re: sudo completion problem

[Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>]

Zefram wrote:

> Andrej Borsenkow wrote:
> >I think, it was the result of change for find (do not have article
> >handy) - in ``find /tmp -user'' -user was not recognised as option
> >because /tmp already was argument. So, this change made options be found
> >everywhere, even after arguments :-)
> 
> That's the wrong way to do it.  In the find command line, `-user' is not
> an option, it's an expression (or part thereof).  The expression starts
> with the first argument that starts with `-' and continues to the end
> of the line; the directory arguments must appear before the expression.
> Actual options are handled as dummy predicates, which is confusing to
> the user, but from our point of view means that they must be treated as
> part of the expression.
> 
> find has a unique syntax, with no options having the usual option syntax.
> Therefore it shouldn't be handled by the standard option completion
> function; it needs a dedicated find-expression completion function.

I don't think we really need this. Especially since it works quite
well for most cases where one would want to complete. We could change
_find to complete normal arguments with a `->foo' action and there
decide if directories or only \!, \( and \) should be completed
(depending on there being an `opion' on the line or not). In that case 
it should do the right thing in every case even if the -* things
aren't really options.

> The standard option completion function should, as is standard syntax,
> process options only before the first non-option argument.

It's a simple `(-)' for the first argument and allows us to use
_arguments both for things like _find *and* for commands with options
after sub-commands (cvs, etc.) and with commands whose command lines
can consist of multiple option/argument pairs (like zrecompile or some 
such). This flexibility is certainly a big win, as I hope you'll agree.


Andrej Borsenkow wrote:

> ...
> 
> This may be useful in other cases as well. cvs comes in mind
> immediately - common options, then checkout, update, etc as argument -
> and possibly (sub-)options and (sub-)arguments for every of them.

Sub-commands (and their options and arguments!) as arguments to
every(!) common option?

What's wrong with the way _cvs works now?

> 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.

For the different-platform problem: the easiest and most readable way
is still and will ever be: a `case ... in ... esac'. Either setting up 
an array of _arguments-specifications or calling _arguments directly.

> 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).

I *really* don't think we should make _arguments do this. I know
_arguments is handy in many cases but it should *not* be the only
function used if that requires to make it more complicated than
compctl ever was.

The main reason for inventing the new completion system was to get at
the flexibility of shell functions, after all. If we want to give help 
completing certain kinds of things we should write new utility
functions that can be combined with existing functions or we should
write wrappers around existing functions (like _argument_sets). But we 
shouldn't put everything into one basket.

> 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).

I don't know what you are alluding to here. When did you complain
about it? And to make me believe that flags would help here I need 1)
a more complete description of how the flags work and 2) examples
where currently `it is hard to add something'.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@xxxxxxxxxxxxxxxxxxxxxxx