Zsh Mailing List Archive
Messages sorted by:
- X-seq: zsh-workers 9766
- From: Peter Stephenson <pws@xxxxxxxxxxxxxxxxxxxxxxxx>
- To: zsh-workers@xxxxxxxxxxxxxx
- Subject: Re: 3.1.6-dev-18
- Date: Wed, 16 Feb 2000 17:41:39 +0000
- In-reply-to: "Sven Wischnowsky"'s message of "Wed, 16 Feb 2000 11:50:25 +0100." <200002161050.LAA17494@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>
- Mailing-list: contact zsh-workers-help@xxxxxxxxxxxxxx; run by ezmlm
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
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@xxxxxxxxxxxxxxxxxxxxxxxx>
Messages sorted by: