Re: CVS directories in completion-ignored-extensions

[Miles Bader]

On Tue, Jan 06, 2004 at 07:55:52AM +0200, Eli Zaretskii wrote:
> The current completion-ignored-extensions machinery is implemented in
> C (see dired.c).  I'm worried about the complexity and performance of
> walking a non-trivial list and trying to match a regexp for every
> file in a directory returned by `readdir'.

I think that's an orthogonal issue -- obviously walking the list isn't too
big a problem (the function example I gave is obviously simple enough to
implement in C if that would be desirable), and if regexps prove to be a
problem, we don't have to use them by default (though my impression was that
as long as they're in the compiled-regexp cache, regexps are actually pretty
darn fast).

I was more interested in the general concept of `string matcher' lists like
this, as I believe they are a very good interface for this sort of thing
(especially for the user -- easy to customize, very clear in raw-lisp, avoids
having dones of `almost the same' variables, etc).

> Possible alternative designs:
> 
>  1) Use shell wildcards instead of regexps, and make
>     `file_name_completion' use `fnmatch' instead of regexp matching.

Note that this is the beauty of the approach I'm advocating -- you can have
multiple match types without adding tons of new variables.

So for instance, we could say that a cons like (shell-regexp SHELL_REGEXP)
used fnmatch or whatever; then the user can use the interface he likes
(which I suppose might often be the case).

>  2) Restructure `file_name_completion', so that it doesn't need to
>     compile the regexps for each file name it examines.

AFAIK, the compiled-regexp cache should make this not much of a problem
anyway (though I'm not really up-to-date on the details).

-Miles
-- 
Freedom's just another word, for nothing left to lose   --Janis Joplin