Zsh Mailing List Archive
Messages sorted by:
- X-seq: zsh-workers 12967
- From: Sven Wischnowsky <wischnow@xxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: multiple-commands-functions
- Date: Wed, 11 Oct 2000 16:56:22 +0200 (MET DST)
- In-reply-to: "Bart Schaefer"'s message of Wed, 11 Oct 2000 14:46:42 +0000
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
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 is equal to `remsh'
> } and if it is, it will call the completion function for `rsh', but
> } before that, it sets $words to `rsh'. I.e. the function only has to
> } check for $words = 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
> Are there any other cases where the format of $words 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 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 will be looked at.
Yes, that's the other way I was thinking about, too...
Sven Wischnowsky wischnow@xxxxxxxxxxxxxxxxxxxxxxx
Messages sorted by: