From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6692 invoked from network); 12 Feb 2002 15:21:55 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 12 Feb 2002 15:21:55 -0000 Received: (qmail 12201 invoked by alias); 12 Feb 2002 15:21:50 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16611 Received: (qmail 12190 invoked from network); 12 Feb 2002 15:21:49 -0000 From: Sven Wischnowsky MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Message-ID: <15465.13002.262337.128763@wischnow.berkom.de> Date: Tue, 12 Feb 2002 16:20:42 +0100 To: zsh-workers@sunsite.dk Subject: Re: ssh completion problem In-Reply-To: <20020212150805.94054.qmail@web9302.mail.yahoo.com> References: <15465.5565.960990.977033@wischnow.berkom.de> <20020212150805.94054.qmail@web9302.mail.yahoo.com> X-Mailer: VM 6.95 under 21.5 (patch 3) "asparagus" XEmacs Lucid Oliver Kiddle wrote: > ... > > > > Where is the right place to add default matches then? > > > > In the function where the outer loops are, because only there can we > > Seems a pity not to allow utility functions to define the default > orders for the things it completes. It reduces the flexibility of > functions in > the inner circle. Yes, that's why I'd like to find a nice solution... > ... > > The idea is simple though. _tags looks up tag-order right? So if _tags > takes an option which specifies a default tag-order. This default is > used unless overriden by a tag-order style. Ahh. I was mostly wondering where you wanted to put those defaults. On that lavel, aha, interesting. > So instead of: > compadd -a tmp || _hosts > we can do > _tags -o '"my-accounts" "not-my-accounts"' my-accounts not-my-accounts > and then the usual tags loop. A user can then change the default order > with a style. We'd need some care to ensure that matches are all added > to the hosts group with a `host' description (I don't see why they > should be necessary to _requested and friends for the many cases when > you just want to pass down the values set in an outer loop (which you > have in "$@")). Hmhm, compadd-option-inheritance is something I've been thinking about, too, lately, in the fake-style discussion. > 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 (so there might aswell then be a separate > label-order style) but such tag-orders only currently work if there is > no tag loop nesting. Also, when looking up the ignored-patterns style, > the _comp_ignore array needs to be augmented so it needs to be > implemented as a sort of stack. I think this solution would lack the > fundamental problems though it does have limitations so I'll be doing > some further thinking. But interesting ideas already... > ... > > > > _netscape. There's also a few cases which look like `_requested > > > I don't see such a case there. Are you aware that _wanted and > > _requested use _all_labels which implements the labels-loop? > > 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). > 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. > PS. You may know anyway but with the recent fake style patch (I think > the _wanted -x one) which you haven't commited, I get problems with > descriptions. grep - for example lists options and descriptions > separately. I haven't tried the very latest patch which has just > arrived in the last few minutes. Yes, I know, it was caused by the changes in the C-code and hence I didn't commit that part. Bye Sven -- Sven Wischnowsky wischnow@berkom.de