case-insensitive completion

case-insensitive completion

[Karl Chen]

Hi, I use the following for case-insensitive completion:
    zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'

It has always been MUCH slower than regular completion, esp on big
directories.  With 4.3.0-dev-5 it got even worse.  This is all on
a local disk (high bandwidth, low latency SATA), though of course
the effect is magnified over NFS.

Any plans to implement case-insensitive matching natively?


-- 
Karl 2006-03-01 01:13

Re: case-insensitive completion

[Bart Schaefer]

On Mar 1,  1:16am, Karl Chen wrote:
} 
} Hi, I use the following for case-insensitive completion:
}     zstyle ':completion:*' matcher-list 'm:{a-z}={A-Z}'
} 
} It has always been MUCH slower than regular completion, esp on big
} directories.  With 4.3.0-dev-5 it got even worse.

I suspect that if you compile with --disable-multibyte you'll at get
at least back to the speed before 4.3.0-dev-5.  I'd be curious to know
if you don't.

} Any plans to implement case-insensitive matching natively?

What do you mean "natively"?  The matcher-list matching is all done
in C, even though it's enabled via zstyle.

Re: case-insensitive completion

[Peter Stephenson]

Bart Schaefer wrote:
> } Any plans to implement case-insensitive matching natively?
> 
> What do you mean "natively"?  The matcher-list matching is all done
> in C, even though it's enabled via zstyle.

And, anyway, "setopt nocaseglob" already exists.

-- 
Peter Stephenson <p.w.stephenson@ntlworld.com>
Web page still at http://www.pwstephenson.fsnet.co.uk/

Re: case-insensitive completion

[Bart Schaefer]

On Mar 5,  5:24pm, Peter Stephenson wrote:
}
} And, anyway, "setopt nocaseglob" already exists.

That doesn't help with matching anywhere but for filenames, does it?

Re: Case-insensitive completion

[Bart Schaefer]

[redirected to zsh-workers from zsh-users]

On Sep 16, 12:09pm, Oliver Kiddle wrote:
} Subject: Re: Case-insensitive completion
}
} Bart wrote:
} 
} > - file-patterns are not tried after the first one that has the pattern
} >   '*:...' which is why the (#I) is thrown in on globbed-files, to force
} >   attempting both globbed-files and ci-globbed-files even if the match
} >   pattern substituted by %p is '*'.
} 
} Yuk. Could you see if there was a good reason for that?

The docs have this example:

     To alter the default behaviour of file completion -- offer files
     matching a pattern and directories on the first attempt, then all
     files -- to offer only matching files on the first attempt, then
     directories, and finally all files:

          zstyle ':completion:*' file-patterns \
              '%p:globbed-files' '*(-/):directories' '*:all-files'

     This works even where there is no special pattern: _files matches
     all files using the pattern `*' at the first step and stops when it
     sees this pattern.  Note also it will never try a pattern more
     than once for a single completion attempt.

} If it is just for efficency it should perhaps be removed.

It appears to be done that way to intentionally short-circuit the process
exactly when %p is '*', so that (in the example above) no redundant group
'directories' is created when both files and directories are already in
the globbed-files group.

The correct behavior (which may be very tough to implement) would seem to
be to check the entire list of tags against the matcher style before the
loop begins, and bail at '*' only if there are no tags left with matchers.