From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 7981 invoked from network); 16 Feb 2000 17:38:15 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 16 Feb 2000 17:38:15 -0000 Received: (qmail 11430 invoked by alias); 16 Feb 2000 17:38:08 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9766 Received: (qmail 11422 invoked from network); 16 Feb 2000 17:38:07 -0000 To: zsh-workers@sunsite.auc.dk Subject: Re: 3.1.6-dev-18 In-reply-to: "Sven Wischnowsky"'s message of "Wed, 16 Feb 2000 11:50:25 +0100." <200002161050.LAA17494@beta.informatik.hu-berlin.de> Date: Wed, 16 Feb 2000 17:41:39 +0000 From: Peter Stephenson Message-Id: 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 ~/. >> >> 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