Zsh Mailing List Archive
Messages sorted by:
Re: ssh completion problem
- X-seq: zsh-workers 16611
- From: Sven Wischnowsky <wischnow@xxxxxxxxx>
- To: zsh-workers@xxxxxxxxxx
- Subject: Re: ssh completion problem
- Date: Tue, 12 Feb 2002 16:20:42 +0100
- In-reply-to: <20020212150805.94054.qmail@xxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxx; run by ezmlm
- References: <15465.5565.960990.977033@xxxxxxxxxxxxxxxxxx> <20020212150805.94054.qmail@xxxxxxxxxxxxxxxxxxxxxx>
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 -<tab> 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.
Sven Wischnowsky wischnow@xxxxxxxxx
Messages sorted by: