Re: ssh completion problem

[Sven Wischnowsky <wischnow@berkom.de>]

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.


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de