Re: completion-ignored-extensions: match full file names

[Eli Zaretskii]

> From: David Reitter <david....@gmail.com>
> Date: Thu, 13 Jan 2011 21:00:57 -0500
> Cc: emacs...@gnu.org
>
> The only (minor) issue I see is the name of the customization variable - at that point, the string no longer represents an extension of the file name.

Neither is ".git/" with the trailing slash. So we are already
extending the notion of ``extension'' here. I see no harm in
extending it some more. If adequately documented, this won't be a
problem, especially since it stays out of user's way unless
deliberately used for this particular purpose.

[Stefan Monnier]

> Each element of completion-ignored-extensions is matched at the _end_
> of the file/directory name of the completion candidates. So I think
> currently what you want is not possible.

> Using regexp syntax is not a good idea, IMO, since that would require
> to rewrite all the customizations users out there have, to escape the
> dot. But I think we could make a change whereby if an element of
> completion-ignored-extensions begins with a slash, that means match at
> the beginning. Then we could have "/.git/" as an element, and that
> would ignore only the standard ".git" subdirectories, not any
> directory that happens to end in ".git".

> WDYT?

I'd much rather add regexp-support, which will give a lot more
flexibility and should be pretty easy to implement. Of course, it will
have to use a new variable since as you point out the current
completion-ignored-extensions aren't compatible with
a regexp interpretation.

Stefan

[Stefan Monnier]

>> I'd much rather add regexp-support, which will give a lot more
>> flexibility and should be pretty easy to implement. Of course, it will
>> have to use a new variable since as you point out the current
>> completion-ignored-extensions aren't compatible with
>> a regexp interpretation.

> I don't object, but this has a disadvantage that we would need to
> start using this regexp-based variable right away, to filter out only
> literally the ".cvs", ".bzr", ".git" etc. directories, not just any
> directory that ends in these extensions. IOW, introducing the new
> variable would mean that the default value of
> completion-ignored-extensions will change and the default value of the
> new variable will be non-nil.

I don't understand in what way it's a disadvantage.

> So it sounds like a more invasive change.

Could be. But it brings more benefit to the end-users.

Stefan