another file completion problem in 4.3.9-dev-2

another file completion problem in 4.3.9-dev-2

[Greg Klanderman]

Here's another file completion problem in 4.3.9-dev-2:

| [~] greg@lwm| zsh -f     
| lwm% echo $ZSH_VERSION
| 4.3.9-dev-2
| lwm% echo $ZSH_PATCHLEVEL
| 1.4662
| lwm% rm .zcompdump
| lwm% autoload -U compinit
| lwm% compinit -u
| lwm% zstyle ':completion:*' matcher-list '' 'm:{a-zA-Z}={A-Za-z}' '+ l:|=* r:|=*'
| lwm% mkdir temp
| lwm% cd temp
| lwm% touch BarBaz

Now if I try to complete "ls baz", I get nothing.

But if I complete "ls az", it does correctly complete to "ls BarBaz".

thanks,
Greg

Re: another file completion problem in 4.3.9-dev-2

[Bart Schaefer]

On May 2, 12:09am, Greg Klanderman wrote:
}
} Here's another file completion problem in 4.3.9-dev-2:
} 
} | [~] greg@lwm| zsh -f     
} | lwm% echo $ZSH_VERSION
} | 4.3.9-dev-2
} | lwm% echo $ZSH_PATCHLEVEL
} | 1.4662
} | lwm% rm .zcompdump
} | lwm% autoload -U compinit
} | lwm% compinit -u
} | lwm% zstyle ':completion:*' matcher-list '' 'm:{a-zA-Z}={A-Za-z}' '+ l:|=* r:|=*'
} | lwm% mkdir temp
} | lwm% cd temp
} | lwm% touch BarBaz
} 
} Now if I try to complete "ls baz", I get nothing.
} 
} But if I complete "ls az", it does correctly complete to "ls BarBaz".

Hmm.  The default completers only include _complete and _ignored.  In
order to get the behavior you want, I also have to allow corrections:

zstyle ':completion:*' completer _complete _ignored _approximate

"baz" is a mismatch in at least two dimensions, both position in the
word (not a prefix) and case.  I suspect the matcher list can adjust
for only one dimension at a time.

On the other hand, the following DOES seem to be a bug, so maybe it
is related somehow:

torch% autoload -U compinit
torch% compinit -D -u
torch% setopt no_case_glob
torch% ls -la    
total 88
drwx------   2 schaefer schaefer  4096 May  2 06:47 .
drwxrwxrwt  27 root     root     69632 May  2 07:15 ..
-rw-rw-r--   1 schaefer schaefer     0 May  2 06:47 BarBaz
torch% ls ba<TAB>

(no result).  Setting no_case_glob is supposed to cause file completion
to be applied case-insensitively even if there is no matcher-list, but
   compfiles -p tmp1 accex '' ' m:{a-zA-Z}={A-Za-z}' '' fake '*'
(line 409 in _path_files) doesn't return any matches in tmp1.

Sigh.  Some documentation (at least in comments) for the functions in
computils.c would really have been helpful.

Re: another file completion problem in 4.3.9-dev-2

[Greg Klanderman]

>>>>> Bart Schaefer <schaefer@brasslantern.com> writes:

> "baz" is a mismatch in at least two dimensions, both position in the
> word (not a prefix) and case.  I suspect the matcher list can adjust
> for only one dimension at a time.

I don't think that's true, it usually works for me, for example:

[~] greg@lwm| zsh -f
lwm% autoload -U compinit
lwm% compinit -D -u
lwm% zstyle ':completion:*' matcher-list '' 'm:{a-zA-Z}={A-Za-z}' '+ l:|=* r:|=*'
lwm% mkdir temp
lwm% cd temp
lwm% touch FooBar FooBaz
lwm% ls baz    # <TAB> ===> FooBaz

> On the other hand, the following DOES seem to be a bug, so maybe it
> is related somehow:

Interesting...

Thanks for taking a look, Bart!

Any thoughts on the other one I sent a couple weeks back, which seemed
to have something to do with quoting of space?

cheers,
greg

Re: another file completion problem in 4.3.9-dev-2

[Bart Schaefer]

On May 3, 12:56pm, Greg Klanderman wrote:
}
} >>>>> Bart Schaefer <schaefer@brasslantern.com> writes:
} 
} > "baz" is a mismatch in at least two dimensions, both position in the
} > word (not a prefix) and case.  I suspect the matcher list can adjust
} > for only one dimension at a time.
} 
} I don't think that's true, it usually works for me, for example:
} 
} lwm% touch FooBar FooBaz
} lwm% ls baz    # <TAB> ===> FooBaz

Right, and look at this:

torch% ls        
BarBaz  FooBaz
torch% ls baz<TAB>
torch% ls FooBaz <cursor>

The only match found is FooBaz.  The condition seems to be that "baz"
matches nothing, and "Ba" matches a prefix of BarBaz, so there's no
futher attempt to find another spot where "Ba" might match -- the
mismatch of "z" vs. "r" discards BarBaz as a possible completion
unless correction is also allowed.

Completion isn't coded like a regular expression engine that will
backtrack and retry until it finds all possible substring hits -- in
fact, when presented with the choice the decision frequently was to
make completion fail quickly even if that meant missing something.
Otherwise it's too easy to get into situations where you hit TAB and
the shell just goes away for minutes at a time.  Some people would
say that's already too easily perpetrated.
 
} Any thoughts on the other one I sent a couple weeks back, which seemed
} to have something to do with quoting of space?

I can't reproduce it using the steps that you outlined.  For example,
at the point where you say --

> OK, now <Control-d> lists:

I can't list with ^D, instead it deletes the backslash character
that is under the cursor.  If I invoke list-choices explicitly, the
cursor moves to the end of the line when the list is displayed, then
moves to the backslash again when I hit TAB; no "o" is inserted.

Is it possible you have some settings creeping in from /etc/z* even
when starting with zsh -f ?  Or perhaps the contents of the several
directories makes a difference -- can you reproduce with empty dirs?