Re: ssh completion problem

[Sven Wischnowsky <wischnow@berkom.de>]

Oliver Kiddle wrote:

> ...
> 
> Did you try the first patch? The second patch was there because it
> demonstrates why I think this problem is more fundamental than just
> _combination. If you just want to get this working, Sven's patch is
> now perhaps a better bet as I see you've now done. Needing two tabs
> is a separate issue which has come up before.

Right, I forgot to answer that.

> A possible solution
> to that might be some value in compstate which if set causes
> completion to have another go if a first match was unambiguously
> added.

I'd try to do that all in shell code, i.e. in _main_complete, but, as
with the fake style, ...

> 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.

> ...
> 
> > Your analysis is basically right, the problem is that _combination
> > doesn't know whether there might be other matches be added for the
> > tag
> > by an outer loop. So I think what is wrong here is _combination
> > adding
> > default matches. I'd think that's simlpy the wrong place to do that.
> 
> Where is the right place to add default matches then?

In the function where the outer loops are, because only there can we
know what other things are to be completed (after all, it's not only
different labels, there might be completely other types of matches --
different tags -- the outermost function will offer).

Of course, as can be seen by the _combination example we are talking
about, functions in the inner circle might have good ideas about *how*
to produce those matches. I've been realtively silent not only because
I have a lot of work here, but also because I'm trying to find a
generic approach to all this.

> 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?

> > One way to circumvent most problems with tag and label loops is to
> > make _combination loop:
> 
> With this there is then two loops for the hosts tag. The inner loop
> allows it to loop over the three labels again so it knows if matches
> are added for each label or not. Note that there are then nine calls to
> compadd. It only works because the final (innermost) label loop is for
> the same tag that is separated into labels. I still am convinced that
> there is a wider problem which this doesn't solve. The second patch
> in my last post is a useful one for seeing the problems.

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.

> > > This is unrelated but out of interest, why is the _next_labels
> stage
> > > skipped in some completion functions?
> > 
> > Could you give me an example, so that I don't need to search?
> 
> _netscape. There's also a few cases which look like `_requested users
> && _users && ret=0' but I suppose they're okay because of _users
> calling _wanted? 

I don't see such a case there. Are you aware that _wanted and
_requested use _all_labels which implements the labels-loop?


Bye
  Sven

-- 
Sven Wischnowsky                          wischnow@berkom.de