hollasch
commented
5 years ago I've decided to go with option 2. .. subdirectories are processed during pattern normalization, before actual pattern matching takes place.
After consideration, the ultimate pattern may indeed be constructed from multiple subpaths, which may themselves include .. subdirectories. At a minimum, this can be expressed in an unsurprising way to the user.
Determine how to handle
..components in patterns. There are several options.1. Forbid
..following any wild characters.Anything before wild characters is considered part of a "rooting" path, and can be understood unambiguously.
2. Allow
..components, but eagerly collapse before matchingFor example, the pattern
/a/b/.../c/../dis simplified to/a/b/.../dfirst, then matched.3. Allow
..components, match only entities that strictly match that pattern.With this mode (the most difficult to fulfill), one could use the pattern
.../obj/../test/to match only test directories that haveobjdirectories as an existing sibling.With such speculative patterns, one could easily expand on this idea to handle capture groups. For example, to match C++ source files with associated tests:/.., but you can see where this heads.
.../test/(*.cpp)/../src/&1or something like that. Of course, that also would require a way to understandThoughts
I'm leaning toward option 1 for the time being. I don't like option 2, because there's no reason you'd want to specify a pattern this way (maybe if you're assembling it programmatically?), and it doesn't really provide any new functionality. Option 3 would be hard, though arguably useful.