From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24926 invoked from network); 15 Feb 2002 17:15:57 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 15 Feb 2002 17:15:57 -0000 Received: (qmail 9083 invoked by alias); 15 Feb 2002 17:15:47 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16659 Received: (qmail 9045 invoked from network); 15 Feb 2002 17:15:34 -0000 Message-ID: <20020215171532.57115.qmail@web9302.mail.yahoo.com> Date: Fri, 15 Feb 2002 17:15:32 +0000 (GMT) From: =?iso-8859-1?q?Oliver=20Kiddle?= Subject: Re: ssh completion problem To: zsh-workers@sunsite.dk In-Reply-To: <15465.13002.262337.128763@wischnow.berkom.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit --- Sven Wischnowsky wrote: > > > One idea I have for solving the main part of the problem is only > doing > > a _next_labels loop around final compadd commands. This loop would > need > > to loop over all labels for every tag for which an _requested is in > our > > funcstack. It would lose some flexibility such as a tag-order like: > > 'hosts:-domain users' 'hosts:-ipaddr ports' > > no longer being possible ... > > ... limitations so I'll be doing some further thinking. > But interesting ideas already... The only other solution I've thought of would be to defer all tag/label loops until the very end after all matches are added. It'd need to track the path of added matches building up a list of associated tags. It would allow the mixed label/tag tag-orders like the example above but be less efficient because unwanted matches would be generated. I think I prefer my first idea which also has the advantage of being closer to the current system. I don't think separate tag and label ordering would matter much. I've still got some lines of thought I want to follow though. If the tags dependence on funcstack to track nested tags loops goes, we may need to act on a tag loop exiting. Currently, we break out of the loops with `(( ret )) || break'. Can't that be done with a compstate[nmatches] test in _tags - I'd prefer if we didn't have to set and test $ret there anyway. > > I'd have expected an _requested if around the _next_label prefixes > loop > > That's only needed when there are two or more possible tags. If the > only tag offered isn't wanted by the user the _tags in the while loop > never returns non-zero (and hence we don't really need a loop there). Ah, that explains. > > and an _next_labels loop inside the _requested urls if. I thought > > _requested only used _all_labels if it got description arguments. > > That's left to the _wanted, _newsgroups and that _tags-loop, it > seems. Okay, but those _wanted calls use a different tag. Labels setup for the urls tag might not then be handled. Cheers Oliver __________________________________________________ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com