From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 680 invoked from network); 11 Oct 2000 14:57:22 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 11 Oct 2000 14:57:22 -0000 Received: (qmail 19594 invoked by alias); 11 Oct 2000 14:56:31 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 12967 Received: (qmail 19586 invoked from network); 11 Oct 2000 14:56:24 -0000 Date: Wed, 11 Oct 2000 16:56:22 +0200 (MET DST) Message-Id: <200010111456.QAA29466@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Bart Schaefer"'s message of Wed, 11 Oct 2000 14:46:42 +0000 Subject: Re: multiple-commands-functions 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 > > ?? 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