From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 24610 invoked from network); 9 Mar 2000 15:09:58 -0000 Received: from sunsite.auc.dk (130.225.51.30) by ns1.primenet.com.au with SMTP; 9 Mar 2000 15:09:58 -0000 Received: (qmail 18218 invoked by alias); 9 Mar 2000 15:09:51 -0000 Mailing-List: contact zsh-workers-help@sunsite.auc.dk; run by ezmlm Precedence: bulk X-No-Archive: yes X-Seq: 10027 Received: (qmail 18196 invoked from network); 9 Mar 2000 15:09:48 -0000 Date: Thu, 9 Mar 2000 16:07:45 +0100 (MET) Message-Id: <200003091507.QAA30731@beta.informatik.hu-berlin.de> From: Sven Wischnowsky To: zsh-workers@sunsite.auc.dk In-reply-to: "Andrej Borsenkow"'s message of Thu, 9 Mar 2000 16:41:51 +0300 Subject: RE: Matching against file suffix Andrej Borsenkow wrote: > > The simple 'r:|.=* r:|=*' works for me, i.e. `foo .../.texi' > > gives me the *.texi files. > > > > Well, I never could completely grok matchers :-) > > Still, it seems, that with above matcher zsh considers only first dot. E.g. > > zstyle ':completion:*:*:files' matcher 'r:|.=* r:|=*' > bor@itsrm2% l > WinNT/ patches/ zsh-3.1.6-dev-15.tar.gz > zsh-3.1.6-dev-16.tar.gz zsh-3.1.6-dev-17.tar.gz zsh-3.1.6-dev-18.tar.gz > zsh-3.1.6-dev-19.tar.gz zsh-3.1.6.tar.gz > bor@itsrm2% l .gz > beeps, but > bor@itsrm2% l .1 > bor@itsrm2% l zsh-3.1.6.tar.gz > Completing file > zsh-3.1.6-dev-15.tar.gz zsh-3.1.6-dev-16.tar.gz zsh-3.1.6-dev-17.tar.gz > zsh-3.1.6-dev-18.tar.gz zsh-3.1.6-dev-19.tar.gz zsh-3.1.6.tar.gz > > I vaguelly remember, that it was once done on purpose. While I agree, that it may be > useful at times - is it possible to have alternate way that matches separators as well? Or > some other way to get the above? Urgh. We had so many problems with that, that I would prefer to not change (or enhance) it again. Hm, a pure suffix test match spec would be `l:|=*' (read: there may be any characters before the word typed). [ Btw. tcsh with complete=enhance does the same -- by which I don't want to say that it is the correct behaviour. ;-] And... > In the above case I'd like being able to say > > gzcat -19TAB (or even -6-19) > and get it expanded to zsh-3.1.6-dev-19.tar.gz this (the `-19', not the `-6-19') is exactly what I use the substring-matcher for: `l:|=* r:|=*' means that there may be any characetrs before or after the word from the line. > > Btw, I have the _match completer in my completer style, but only after > > all the matcher-list specs have been tried (which include the one > > above and the substring-matcher `l:|=* r:|=*'). > > That reminds me. Matcher-list is way too general - it applies to any completion in any > context. And matcher is tried unconditionally, isn't it? I'm not sure what you mean by `unconditionally' -- I always consider the context for which it is set to be a `condition'. > Is there any feasible way to add > per-tag matcher-list? So, that one could say > > *files matcher-list ... I've been dreaming about this, too. But -- as you can see -- I didn't find a solution. There are actually two problems: - Testing multiple patterns would require a loop somewhere. Since nobody will suggest that every completion function should implement such a loop, we could put it in compadd (i.e. in C-code). We would then need another option to give it a bunch of match specs to try one after another. That's not too hard. But: - The second problem is to decide when to try the next pattern. Consider a context where we can add more than one type of matches. Here we almost certainly first want to try all types with the first match spec, then try all types with the next pattern and so on. In other words: we can write the loop only in the completion functions. Even worse: only in the top-level functions. And now think about functions like _users which are sometimes called as top-level functions and sometimes as utility functions. And we can't put the loop(s) in a function further up (like _normal), because we don't know about the tags there. Sigh. Bye Sven -- Sven Wischnowsky wischnow@informatik.hu-berlin.de