From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 2986 invoked from network); 29 Mar 2001 14:09:54 -0000 Received: from sunsite.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 29 Mar 2001 14:09:54 -0000 Received: (qmail 900 invoked by alias); 29 Mar 2001 14:09:46 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 13839 Received: (qmail 881 invoked from network); 29 Mar 2001 14:09:45 -0000 Date: Thu, 29 Mar 2001 16:09:45 +0200 (MET DST) Message-Id: <200103291409.QAA20643@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.dk In-reply-to: "Bart Schaefer"'s message of Thu, 29 Mar 2001 08:47:11 +0000 Subject: Re: PATCH: Re: Backticks and other tricks Bart Schaefer wrote: > On Mar 29, 10:14am, Sven Wischnowsky wrote: > } > } 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. > > The only thing that worries me, given this explanation, is clusters of > single-letter options, like some of the very specialized cases in _rpm. > A whole lot of work went into making those cluster in just about every > ordering that might make sense to rpm, and some of them are pretty odd; > for example, -i means something different when it's the first option on > the line than it does when it follows -q, so `rpm -iq...' completes > differently from `rpm -qi...'. I've been thinking about this all day. How is this different from the situation I wanted to fix with the change? The problem there was that after a ->state action for an argument in the same word as the option was used, the option itself was added as a possible completion. In functions like _rpm, where we have to handle multiple single-letter options in the same word and probably `nested' calls to _arguments the situation is the same. If _arguments has found out that we are after an option whose argument has to come exactly at the point where the cursor is, in the same word (I seem to be repeating this a lot, but that's the whole point), then we are in a place where no other option can be needed anyway (from the program for which we are completing). And if we are after a single-letter option after which options of some sub-command have to be completed this is exactly the same as if there were an option with a argument (and it's written like that in functions like _rpm). And note that the action will still be taken (i.e. reported to the calling function), it's just that no more options of the upper-level call to _arguments will be completed at that position. And that should be logically correct, because after the sub-command-like-option only the options for the sub-command are to be completed which will be handled by the action. Or maybe I'm just getting blind... > It doesn't *appear* that anything has gone wrong with it, but there are > so many possible combinations to try ... Yes. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de