On Sun, Jun 22, 2008 at 11:23:42PM +0100, Peter Stephenson wrote: > It's something to do with using the -U argument to compadd when you've > got ambiguous completions: it works fine when there's only a single > completion. It was triggered by adding the -U's to do approximation in > non-final path segments (even before the compmatch change). The initial > "." is a red herring. However, I don't know where it's going wrong > since when I do approximation after normal completion (but lots of other > options set, too) it works fine. This triggers a different part of > _path_files which has compadd -U but slight differences in the other > arguments. Internally the Cline struct that's used for generating the > command line looks a bit spartan in the failed case. Needless to say I > haven't the faintest clue where this is leading.
Further clues: 1) these behave the same way zstyle ':completion:*' completer _complete _ignored _match _approximate zstyle ':completion:*' completer _complete _correct _approximate zstyle ':completion:*' completer _complete _approximate 2) this one behaves the same way on the second tab zstyle ':completion:*' completer _list _expand _complete _ignored _match _correct _approximate _prefix I have not performed an exhaustive search by any means, but I have not yet run across a combination where the inclusion of _approximate doesn't trigger the surprise elision. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
