RE: Matching against file suffix

[Sven Wischnowsky <wischnow@informatik.hu-berlin.de>]

Andrej Borsenkow wrote:

> > The simple 'r:|.=* r:|=*' works for me, i.e. `foo .../.texi<TAB>'
> > 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<TAB>
> 	beeps, but
> bor@itsrm2% l .1<TAB>
> 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<TAB>', not the `-6-19<TAB>') 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