Open BartMassey opened 1 year ago
I can see this being useful. My original intention was to limit the scope to only matching strings, but if the optimized algorithm here would work well for paths as well, then that might make sense too. On the other hand, that would duplicate a lot of behavior from the glob
crate...
I think duplicating the matching behavior of the glob crate would be great, given your performance.
I'm confused by "only matching strings". In wildflower
, does a*c
match "a/b/c"
? I would have expected not, since wildcard matching generally runs implicitly on paths, but maybe so? If so, what use case are you targeting where wildcard matching is preferred over general regex matching?
I think duplicating the matching behavior of the glob crate would be great, given your performance.
Yes!
I'm confused by "only matching strings". In wildflower, does a*c match "a/b/c"? I would have expected not, since wildcard matching generally runs implicitly on paths, but maybe so? If so, what use case are you targeting where wildcard matching is preferred over general regex matching?
a*c
currently matches a/b/c
, yes, making it path-unaware, more like traditional wildcard matching than path globbing.
The original use case I envisioned (and needed for my own project) was allowing end users to define their own simple patterns without having to bring in something larger and complicated (and arguably more exploitable) like regex
. For example, I have a personal transit tracking app I've been working on where there's a search functionality that would benefit from wildcards or better fuzzy matching. This crate fills that need pretty decently.
Windows supports patterns with
**
to match arbitrary path segments: for example,a\**\b.txt
matchesb.txt
in any subdirectory ofa
. It would maybe be good ifwildflower
supported this also. It's a little twitchy, since UNIX not only doesn't have this but will interpret**
in patterns as just*
.