From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 18010 invoked from network); 15 Feb 2000 10:30:09 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 15 Feb 2000 10:30:09 -0000 Received: (qmail 22801 invoked by alias); 15 Feb 2000 10:30:02 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 9738 Received: (qmail 22785 invoked from network); 15 Feb 2000 10:30:01 -0000 X-Envelope-Sender-Is: Andrej.Borsenkow@mow.siemens.ru (at relayer goliath.siemens.de) From: "Andrej Borsenkow" To: "Sven Wischnowsky" , Subject: RE: 3.1.6-dev-18 Date: Tue, 15 Feb 2000 13:29:57 +0300 Message-ID: <000601bf779f$9b599cf0$21c9ca95@mow.siemens.ru> MIME-Version: 1.0 Content-Type: text/plain; charset="koi8-r" Content-Transfer-Encoding: 7bit X-Priority: 3 (Normal) X-MSMail-Priority: Normal X-Mailer: Microsoft Outlook IMO, Build 9.0.2416 (9.0.2910.0) In-reply-to: <200002150943.KAA11806@beta.informatik.hu-berlin.de> Importance: Normal X-MimeOLE: Produced By Microsoft MimeOLE V5.00.2919.6700 > > > Still, how much do you gain by being able to put them in matcher-1 and > > matcher-2? Is that more powerful than just using array elements of the > > style in order, rather than simply more cumbersome? The only examples I > > can think of where you gain something are where _matcher is followed the > > second time by _prefix instead of _complete (or vice versa), or > where some > > other element of the context is different between the matcher-1 and > > matcher-2 cases. These seem to me to be to abstruse to be > useful. But I > > may well have missed something. > > I can only repeat... I would have no problems with turning the matcher > style as used by _matcher (or even renaming it for clarity) into one > that is used as an array. The first _matcher would then use the first > string in the value, the second one the second string and so on. I > just thought -- and I may very well be wrong here -- that it would > make users more aware of what they are doing if we use this more > explicit setting we have now. I.e., even with the suggested > array-interpretation of the matcher style one would have to add a new > call to _matcher in the completer list when adding a new string to the > matcher style. > Please, no. It will be worse than it is now. When I spoke about array, I meant absolutely different thing. Remove _matcher completer alltogether. Setup a style with match specs, that will be tried in order. In other words zstyle :completion::complete::::: match_specs "" spec1 spec2 ... with semantics _complete should try this list in order until it gets matches. I agree, that your way provides more fine grained control ... the question is, how complex completion system is going to be? Do you think, that an everage user would ever need such a complexity? And what occured to me ... why _oldlist, _prefix etc are completers at all? They look much more like actually a styles to me! They do not generate any matches - rather, they say completion system _how_ to generate matches. So, somewhat revolutionary ;-) idea: leave only _complete use styles to describe, just how _complete should do completion. Something like :completion::complete:::::pass-1 flags normal :completion::complete:::::pass-2 flags prefix :completion::complete:::::pass-3 flags match keeplist :completion::complete:::::pass-4 flags approximate prefix and additional :completion::complete:::::pass-1 match_specs "" spec1 spec2 with semantics first try normal with completion with empty, spec1, spec2. If nothin works, try prefix; if this fails, try match keeping old list; and if this fails, try approximate. /andrej