Re: _approximate and _path_files

Re: _approximate and _path_files

[Sven Wischnowsky]

Andrej Borsenkow wrote:

> Do they work together? Assuming that I have directory /archive/sni/mr,
> 
> cd /archive; l sin<TAB>
> 
> gives me `sni'
> 
> but simple
> 
> l /ar/sin<TAB>
> 
> after *very* long time beeps.
> 
> If not - it's really a pity.
> 
> Actually, enabling _approximate (I have max-erros 3) and trying to complete any
> non-existing partial path takes really long time. Hmm ... looks, like zsh simply
> hangs (or better said, loops) currently. I have to press ^C to be able to enter
> something. ^C then returns to my input I tried to complete.

Damn, damn, damn. We lost this when we made braces in path prefixes
and suffixes work. The problem is that the compadd function
_approximate uses sticks the (#a...) at the beginning of the whole
string and then the C-code thinks that this doesn't match because it
doesn't compare the whole strings (including the prefixes and
suffixes), and that is the other way to look at the problem.

We can't just make the compadd() in _approximate to put the (#a...)
somewhere else because we don't know anything about separator
characters used in the calling function.

So we have to fix it in C... and I don't know yet how this is done
best (without losing too much of, e.g., the prefix matching stuff).

Bye
 Sven


--
Sven Wischnowsky                         wischnow@informatik.hu-berlin.de

_approximate and _path_files

[Andrej Borsenkow]

Do they work together? Assuming that I have directory /archive/sni/mr,

cd /archive; l sin<TAB>

gives me `sni'

but simple

l /ar/sin<TAB>

after *very* long time beeps.

If not - it's really a pity.

Actually, enabling _approximate (I have max-erros 3) and trying to complete any
non-existing partial path takes really long time. Hmm ... looks, like zsh simply
hangs (or better said, loops) currently. I have to press ^C to be able to enter
something. ^C then returns to my input I tried to complete.

/andrej