Quoth Rob Browning on Jan 31 at 1:19 pm: > Austin Clements <amdragon@MIT.EDU> writes: > > > folder: could work the way I suggested (simply the path to the file, > > with {cur,new} stripped off). > > Hmm, so would notmuch try to guess whether or not it's dealing with a > maildir++ tree, and if so convert folder:foo to a search of .foo, and/or > folder:foo/bar to .foo.bar? Or would the user just need to know to say > folder:.foo and folder:.foo.bar? My opinion on this has changed over time, but I don't think we should try to interpret Maildir++ trees specially. That is, the user would have to say folder:.foo.bar if they're using Maildir++. The "." seems as good as a "/" for a separator, so we might as well not translate it. The leading "." is annoying, but *shrug* so is Maildir++. > And if we're only planning special treatment for for maildir-like > stores, then I wonder if the term should just be maildir:? The simple algorithm of taking the relative path and stripping {new,cur} (if present) does a good job of supporting both Maildir and non-Maildir stores (while balancing this support with simplicity, predictability, and usability). > Though folder: would make more sense if the long-term goal was to have a > "DTRT" term. But in that case, I wonder if it might eventually be > expected to support mixed trees, i.e. say a tree containing maildir++ > and mh subdirs, and if so, how that should be handled. The simple {new,cur}-stripping algorithm already does fairly well at this. Worrying more about mixed Maildir++ and MH stores seems unnecessary to me unless someone demonstrates and actual need. > > many shells support "**" for recursive path matching and people are > > already quite familiar with glob patterns for paths, so why not simply > > adopt this? > > rsync too. Ah, sure enough. Even better!