Re: _multi_parts and -q

[Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>]

On Sat, 18 Jun 2011 13:03:34 -0700
Bart Schaefer <schaefer@xxxxxxxxxxxxxxxx> wrote:
 On Jun 18,  8:52pm, Peter Stephenson wrote:
> } 
> } _tst() {
> }   local expl_type="stuff"
> }   local -a datasetlist
> }   datasetlist=(foo bar rod stuff)
> }   local pref
> }   [[ $PREFIX = */* ]] && pref=${PREFIX%/*} 
> }   [[ -n $pref ]] && datasetlist=($pref/${^datasetlist})
> }   _wanted dataset expl "$expl_type" _multi_parts -S/ -q / datasetlist;
> } }                     
> } 
> } simply to get strings to compile.  I don't think that should matter.
> 
> I get Danek's reported behavior if the strings in datasetlist actually
> contain the separator.  Try the above with
> 
> datasetlist=(xy/foo xy/bar yx/rod stuff xy/yx/xy)
> 
> So perhaps Danek's problem is with the input data?

I'm seeing something similar with the "xy/" bit with that data, i.e
completing "x" produces "xy/" with a non-removable "/".

I think the issue is that "xy/foo", "xy/bar" etc. look like a set of
ambiguous completions with "xy/" as prefix --- and in *that* case the
"/" isn't special, it's just part of the input string.  (Possibly you
can see some behaviour that disagrees with this hypothesis.)

So the reason I wasn't seeing it is that I was only offering completions
for the current level, i.e. I'd only be offering "xy", "yx" and "stuff"
at this point, after which the "/" is a suffix & separator with the
expected behaviour.

So if it's possible to generate the completions in that fashion (some
more sophisticated variant of the ${PREFIX%/*} business in the function
I was using), I think that would be a workaround.

It might be possible to wrap _multi_parts so as to get this behaviour
generically --- the doc suggests it's deliberate that _multi_parts
doesn't have quite the one-component-at-a-time behaviour you'd expect
with files.

-- 
Peter Stephenson <p.w.stephenson@xxxxxxxxxxxx>
Web page now at http://homepage.ntlworld.com/p.w.stephenson/