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

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

[Sven Wischnowsky]

I forgot to say:

> ...
> 
> Maybe we should only think about `ways to get certain informations'
> instead of `parameterizing commands'.

Of course this also means that this may not be restricted to commands 
we currently call with $(...). Hm. Sounds interesting, I think, but
leaves us with the problem of finding the places where this would be
worthwhile to make it configurable without turning all completion
functions into collections of calls to _call.

Bye
 Sven


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

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

[Sven Wischnowsky]

Alexandre Duret-Lutz wrote:

>  Sven> The only problem is that -- in cases like the _diff -- the users would 
>  Sven> have to know what the command has to do, but as long as we keep tags
>  Sven> and styles documented...
> 
> Could there be a way to make the completion 
> functions autodescribe themselve?  (i.e.  
> print styles and tags used by the function, 
> as well as other info worth to know, in some 
> standard way).  Perhaps it can be made by 
> using some special comments in the completions 
> functions and having a simple shell 
> function that take a command as argument, 
> that find the completion function
> associated and format out these comments.

For the tags there is alread _complete_help, but, as I already said
some time ago (answering a question from Andrej, I think): we can't
really find out which styles are used by a function for a certain
context because they can be tested anywhere and anytime. Because of
that I was thinking about some comment-collecting function like what
you suggested. Finding the functions (and -files) that are used is
simple (_complete_help already does that). The problem is the amount
of work that has to be done to write the comments.

And if we do that we should first try to define a comment-format
containing everything we probably might want to find out about
completion functions and that can also be used to automatically
generate tables/lists for the manual/info.

Bye
 Sven


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

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

[Alexandre Duret-Lutz]

>>> "Sven" == Sven Wischnowsky <wischnow@informatik.hu-berlin.de> writes:

[...]

 Sven>                                       So, maybe we should just make
 Sven> _call get the suggested command line and let users override them
 Sven> completely or leave them alone. I would then make _call take a tag as
 Sven> its first argument which is used to look up the style `command'

This looks easy to use.

[...]

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

Could there be a way to make the completion 
functions autodescribe themselve?  (i.e.  
print styles and tags used by the function, 
as well as other info worth to know, in some 
standard way).  Perhaps it can be made by 
using some special comments in the completions 
functions and having a simple shell 
function that take a command as argument, 
that find the completion function
associated and format out these comments.

[...]

-- 
Alexandre Duret-Lutz

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

[Sven Wischnowsky]

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