From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6603 invoked from network); 12 Feb 2002 15:08:14 -0000 Received: from sunsite.dk (130.225.247.90) by ns1.primenet.com.au with SMTP; 12 Feb 2002 15:08:14 -0000 Received: (qmail 7632 invoked by alias); 12 Feb 2002 15:08:08 -0000 Mailing-List: contact zsh-workers-help@sunsite.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 16610 Received: (qmail 7619 invoked from network); 12 Feb 2002 15:08:07 -0000 Message-ID: <20020212150805.94054.qmail@web9302.mail.yahoo.com> Date: Tue, 12 Feb 2002 15:08:05 +0000 (GMT) From: =?iso-8859-1?q?Oliver=20Kiddle?= Subject: Re: ssh completion problem To: zsh-workers@sunsite.dk In-Reply-To: <15465.5565.960990.977033@wischnow.berkom.de> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit Sven Wischnowsky wrote: > > Needing two tabs is a separate issue which has come up before. > > It'll be more complicated if l@b is to complete to lll@bbb.com > > though. > > ...I think we should also do that in those utility functions, where > it > is useful, i.e. _user_at_host. At least that was the idea we had at > the bginning, leading to functions like _sep_parts. It's easier for _sep_parts though because all it has is an array of values for each part. I have at home a _sep_parts like function which takes _alternative like specs so can call things like _user. Without relying on compadd's -O, I couldn't see how to get it to do this sort of thing. > > 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. > > Having a way to > > specify a default tag-order would seem the most logical to me. > > I'd like to hear more about this (so that I understand what exactly > you mean) and how it could solve -- as an example -- the case we are > discussing here. Maybe you are thinking about something similar and > have a solution in mind? Firstly, I should point out that I don't think this is a solution to the problem. It is just that setting defaults with || is inflexible. 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. 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 "$@")). 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. > Yes, I know how this works ;-) And I also see that this is a wider > problem (see above). If I had thought this were the solution, I'd > have committed the patch. Sorry, I was under the impression that you thought that patch was a solution once we'd got the description down to _combination. > > _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 and an _next_labels loop inside the _requested urls if. I thought _requested only used _all_labels if it got description arguments. Cheers Oliver 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. __________________________________________________ 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