From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19928 invoked from network); 29 Mar 2001 08:14:44 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Mar 2001 08:14:44 -0000 Received: (qmail 2652 invoked by alias); 29 Mar 2001 08:14:38 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13828 Received: (qmail 2640 invoked from network); 29 Mar 2001 08:14:37 -0000 Date: Thu, 29 Mar 2001 10:14:38 +0200 (MET DST) Message-Id: <200103290814.KAA14298@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.dk In-reply-to: =?iso-8859-1?q?Oliver=20Kiddle?='s message of Wed, 28 Mar 2001 16:20:53 +0100 (BST) Subject: Re: PATCH: Re: Backticks and other tricks Oliver Kiddle wrote: > --- Sven Wischnowsky wrote: > > > > Anyway, what I really wanted to say (and that's why it's on > > -workers): > > if you try this with a `&& return 0' after the `_arguments ...' > > you'll > > notice that competion after, e.g. `-ef1:' yields nothing. That's a > > result of the change that removed the 300-return-value -- it has > > added > > the option itself and hence `_arguments' returns zero. Ugly. Very. > > I agree that it is a pity this can't be done anymore when you have > state ->actions but I don't think it is as ugly as using > compstate[nmatches] would be. We just have to use `&& ret=0' or similar > and rely on checking of $state. The only other thing I can think of is > modifying _main_complete to use compstate[nmatches] when deciding > whether to move on to the next completer and allowing completion > functions for commands to not bother about their return code. I'm not > sure I like that though. I'm sure I don't like it. It would be quite sensible to write a completer that adds something but return non-zero -- effectively offering just some extra matches. > > So for now let's use the patch below. It adds the options only if > > there is no `->state' action to use or if we are not in the same word > > after the option. > > I don't really understand this but it sounds like you're not going to > be adding options in cases where they should be - options and states > can both add matches together. It not only sounds like that. But it isn't as bad as it sounds, actually I quite like it after thinking it over again. The patch makes be *not* completed only if 1) a `->state' action was executed (i.e. prepared) *and* if 2) the matches for the `->state' have to be completed in the same word after the option. If the option-argument comes in its own word, options are completed. The only case where the patch would cause trouble is that there are two (or more) options, one being a prefix of the other and the prefixish one gets an argument that has to come directly after the option. A *very* seldom case I would say. And I would guess that in most or all occurrences of such a situation the possible completions for the option-argument are simple enough to not require a `->state' action in which case this should work, too. > Once we have this finalised, I will go through checking the return > codes of functions (and adding -A "-*" and -S options to _arguments) > but I don't have much time over the next two weeks. I hope the return-value behaviour of _arguments is in the final form. Bye Sven P.S.: Why does your MUA put your name into =?iso-8859-1?...?= ? -- Sven Wischnowsky wischnow@informatik.hu-berlin.de