_call (was: Re: PATCH: _diff (new), _prcs (upgrade))

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Alexandre Duret-Lutz wrote:

>  Sven> The only problem is that this means that such options will always be
>  Sven> combined with the ones a user might define in a style. I.e. there are
>  Sven> actually two types of options a completion function might give to a
>  Sven> command: those that *have* to be there to make it work in the way the
>  Sven> function needs it (like the -v for diff) and those the completion
>  Sven> functions *suggests* to use -- which may be overridden by a user's
>  Sven> style. Ideally, we should support both cases...
> 
> Yes, I was speaking of what you call *suggested* options.  As for now, to
> set these options, we should set a default style in compinit or elsewhere.
> But since these *suggested* options must be quite uncommon, this is not a
> problem. ok.

I was about to start writing _call when I was brought to a halt,
because, thinking again and looking at some of our functions, I'm not
so sure about the two different kinds of arguments/options any more.

Maybe we should only think about `ways to get certain informations'
instead of `parameterizing commands'. My suggestion already allowed to 
give other commands with styles but if someone really configures a
completely different command the options supplied by the calling
function may be completely senseless. So, maybe we should just make
_call get the suggested command line and let users override them
completely or leave them alone. I would then make _call take a tag as
its first argument which is used to look up the style `command'
(somehow I think this is cleaner than using a standard tag and
different style names). Maybe we should even make _call concatenate
these arguments (or the strings it gets from the style) and eval the
whole thing so that users can define pipelines to be executed. E.g.,
in _pids we would use `_call pids command ps' and
`_call display command ps' (or maybe without the `command'). In
_diff_options we would use `_call diff-version diff -v' and so on.

The only problem is that -- in cases like the _diff -- the users would 
have to know what the command has to do, but as long as we keep tags
and styles documented...

And it looks much cleaner to me than the auto-option and auto-command
magic we were discussing before.

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de