Re: multiple-commands-functions

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

Bart Schaefer wrote:

> On Oct 11,  9:32am, Sven Wischnowsky wrote:
> } 
> } Then Bart and I more-or-less suggested to use those `services' as an
> } abstraction so that functions could use `#compdef rsh remsh=rsh...'.
> } The service name would then be given as an argument to the function
> } and it could decide what to do with it.
> } 
> } But that has an ugly side-effect: some of the functions already use
> } the arguments, for options.
> 
> Hrm.  That's easily fixable, though.  E.g. in _pbm, you'd just have to add
> an extra argument as $1 when making the recursive call, to identify it as
> "the recursive call service".

And then one would have to remember that the utility functions don't
need that, but the multi-functions-used-as-utilities do.

> ...
>  
> } That made me think about ways to simplify it, or to report the service 
> } somewhere else, in a (completion-system-)global parameter. From there
> } it was only a small step to the patch below. It allows to define
> } `completion aliases' (there it is again, `aliases' -- well, we could
> } change that name, of course). For example, in an autoloaded function,
> } `#compdef rsh remsh=rsh' defines the alias `remsh=rsh'. The code
> } calling completion functions checks if $words[1] is equal to `remsh'
> } and if it is, it will call the completion function for `rsh', but
> } before that, it sets $words[1] to `rsh'. I.e. the function only has to 
> } check for $words[1] = rsh. Put the other way, `rsh' is the `service'.
> 
> Hmm.  What happens if the completion is attempted like:
> 
> zsh% /usr/local/bin/krsh <TAB>
> 
> ??  It doesn't look as though that will work properly.

I only remembered that after I sent it (but have put it into my list
as a if-..-then). It could be solved by changing how _normal looks up
these aliases.

> Are there any other cases where the format of $words[1] could mess up a 
> simple aliasing scheme?  The advantage of the previous proposals was
> that they changed the call to the completion function, not the way it
> was looked up, so there wasn't any chance for this kind of confusion.

Hm, ... I was mostly wondering if changing $words[1] could affect
other places that is used.

> If we do go with this sort of aliasing, one other thing I'd suggest is
> that it be possible to combine this with -p so that the left-hand-side
> could be a pattern, e.g.
> 
> 	compadd -p -A '*r(em|)sh=rsh'
> 
> but perhaps that's not useful enough to be worth the effort.

Dunno, easy to implement, though.

> } The only thing we would have to worry about is functions that call the 
> } command we are completing for. Since this is needed less often than
> } finding the `service', it would probably make sense to put the
> } original command name into a (completion-system-)global parameter and
> } use that everywhere we need to call the command.
> 
> In spite of the "needed less often" argument, I'd still recommend putting
> the service in a different parameter and leaving $words alone.  If the
> positionals won't work, then invent another parameter (local to _normal
> but "global" to the called functions) to store the service.  Most of the
> time there'll be a one-to-one mapping between functions and services and
> neither the service parameter nor $words[1] will be looked at.

Yes, that's the other way I was thinking about, too...

Bye
 Sven


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