Re: 3.1.6-dev-18

[Peter Stephenson <pws@pwstephenson.fsnet.co.uk>]

Sven Wischnowsky wrote:
> Err, hadn't thought about putting that into _main_complete (where we
> can optimise).
> 
> One last question: wouldn't it then be better to just have a
> matcher-list style, taken as an array, containing the match specs to
> try one after another?

Under those circumstances, probably yes; there's no obvious advantage in
pretending you have multiple matching functions if you don't.

>> Firstly, I did
>> 
>> % less ~/.<TAB>
>> 
>> and got a list of files not beginning with a dot amongst those which did.
>
> I don't get that. Let me guess: somehow you ended up with your
> 'r:|[.,_-]=* r:|=*' match spec being tried immediatly or used always
> (as would happen with your setup from 9700, because the matcher style
> is tested for every tag).

That's probably right.  I imagine what confused me is exactly the change we
are discussing above, i.e. I only added one _matcher, which contains the
spec in question which is therefore applied immediately, whereas before it
happened later because it was in the second element of $compmatchers.
So I can easily fix it using styles.

> But maybe we should make _multi_parts use the `expand=suffix'
> style/value to decide if the whole matches should be used at all. The
> same way _path_files does that. I would prefer to make it use an empty 
> tag then (because _multi_parts doesn't always complete paths and the
> style is tested for the paths tag in _path_files). Because of that I
> thought, I should ask first. Or maybe making it use the paths tag in
> _path_files and no tag in _multi_parts is ok? (I find that a bit
> confusing).

Empty tags are certainly easier than they were before, so I would be in
favour of changing not to use tags unless they actually discriminate
between different cases ---- depending really on logic, i.e. we have less
need of inventing otherwise unused tags.

-- 
Peter Stephenson <pws@pwstephenson.fsnet.co.uk>