Better wildcard support

Have a suggestion for "Everything"? Please post it here.
Post Reply
DerpMcDerp
Posts: 5
Joined: Sat Jul 23, 2016 11:12 pm

Better wildcard support

Post by DerpMcDerp »

1. Support vim style wildcards

vim has 2 kinds of wildcards * and **:

"*" is equivalent to the regex [^/\\]*
"**" is equivalent to the regex .*
3 or more consecutive asterisks collapse to "**"

Everything should implement a similar scheme. This makes it significantly easier to do things like limiting the search to a single folder depth or constraining a wildcard search to a specific tree level.

2. If the "Match path when a search term contains a path separator" and "Match whole filename when using wildcards" options are checked, Everything should act as if the query has "**" prepended to it if the query string contains any path characters. e.g.:

\foo* == **\foo* (!= foo*)
down\load*\foo* == **down\load*\foo*
*load\foo == **load\foo
?own\load\foo == **?own\load\foo
:\foo\asdf* == *:\foo\asdf*
c:\foo\asdf* (!= **c:\foo\asdf*)
Last edited by DerpMcDerp on Wed Jul 27, 2016 9:19 pm, edited 4 times in total.
void
Developer
Posts: 16754
Joined: Fri Oct 16, 2009 11:31 pm

Re: Better wildcard support

Post by void »

I'll consider adding an option to do so.

** could also be used to force path matching on.

Thanks for the suggestion.
therube
Posts: 4979
Joined: Thu Sep 03, 2009 6:48 pm

Re: Better wildcard support

Post by therube »

What version of Vim?
Do you have to use some particular switch in order for * vs ** to be effective?

Should something like this return results?

s/g**/xxx/

I get:
E61: Nested *
E476: Invalid command

Though this works

s/g.*/xxx/
"*" is equivalent to the regex [^/\]*
Just what is that construct saying?
DerpMcDerp
Posts: 5
Joined: Sat Jul 23, 2016 11:12 pm

Re: Better wildcard support

Post by DerpMcDerp »

void wrote:I'll consider adding an option to do so.

** could also be used to force path matching on.
Can you make "#:" be a synonym for the regexp "[0-9]+" (or maybe "\p{Nd}+" to support unicode) so we can match filenames containing numbers easier? Everything makes "$foo" mean the same thing as "*$foo*" unless a wildcard character appears. In this particular case, "#:" shouldn't trigger that behavior, i.e. "blah#:" should mean the same thing as "*blah#:*".
therube wrote:What version of Vim?
Do you have to use some particular switch in order for * vs ** to be effective?

Should something like this return results?

s/g**/xxx/
It's not in vim's regex pattern syntax, it's in vim's file syntax:

http://vimdoc.sourceforge.net/htmldoc/e ... #wildcards
"*" is equivalent to the regex [^/\\]*
Just what is that construct saying?
Match all non-path separator characters. i.e. only work on a single path segment rather than an arbitrary number of path segments.
Last edited by DerpMcDerp on Wed Jul 27, 2016 9:19 pm, edited 1 time in total.
void
Developer
Posts: 16754
Joined: Fri Oct 16, 2009 11:31 pm

Re: Better wildcard support

Post by void »

Can you make "#:" be a synonym for the regexp "[0-9]+" (or maybe "\p{Nd}+" to support unicode) so we can match filenames containing numbers easier? Everything makes "$foo" mean the same thing as "*$foo*" unless a wildcard character appears. In this particular case, "#:" shouldn't trigger that behavior, i.e. "blah#:" should mean the same thing as "*blah#:*".
Everything 1.4.1 will support perl compatible regex (PCRE).
You can search for \d to match digits with PCRE.
However, Regex would have to be enabled, or use the regex: modifier.
Everything 1.4.1 will be out soon.

Adding #: when regex is disabled is a little tricky as the current string comparison functions are not designed to do this. Adding this functionality would slow down all searches.
I'll consider detecting #: or something similar which would be replaced with \d and force regex on.
DerpMcDerp
Posts: 5
Joined: Sat Jul 23, 2016 11:12 pm

Re: Better wildcard support

Post by DerpMcDerp »

void wrote:Adding #: when regex is disabled is a little tricky as the current string comparison functions are not designed to do this. Adding this functionality would slow down all searches.
If you add "**" and "*" support, technically you need a search that can backtrack for a correct implementation of certain non-common cases. As a heuristic, only if "**" is mixed with "*" in a query (and "**" don't appear at the beginning or end), should a backtracking search be attempted which should handle the vast majority of common cases.
void wrote:I'll consider detecting #: or something similar which would be replaced with \d and force regex on.
I hope you mean "#:" will translate a wildcard query into a regexp internally rather than merely replacing "#:" with "\d+" and act as if regex: was used.

i.e. ".*#:" should mean "(?:^|\\)[.][^\\/]*\d+(?:$|\\)" instead of ".*\d+"
Post Reply