Austin Clements <amdragon@MIT.EDU> writes: > As a consequence, all folders are subfolders of the inbox. With > recursive search, a search for your inbox folder returns *all* of your > messages. I wasn't trying to say that we shouldn't support recursive > search (I'm all for flexibility), but it's a confusing default for > Maildir++ because of this. > > Maildir++ has the added twist that the inbox folder has no name. As a > result, currently notmuch can't search for a Maildir++ inbox folder, > which needs to be addressed somehow. The least surprising approach > would compatibility with the Maildir++ convention of calling the > top-level folder INBOX, the subfolder INBOX.work, etc. Just adding my agreement here. With recursion and no anchors, "folder:" really won't work for the inbox for Maildir++. > Maildir++ issues aside, I submit that rooted, non-recursive folder > searches are a more natural default with a more conventional syntactic > extension to non-rooted/recursive searches. In > id:87aaiy3u65.fsf@yoom.home.cworth.org, you mentioned that you > implemented non-rooted folder search to mimic subject search. But file > system paths are not natural language like subject lines. File system > paths are hierarchical and rooted. > > Of course, special query operators like ^ and $ can mitigate this, but > these queries *aren't* regexps and, furthermore, people don't usually > apply regexps to file names. They apply globs. Glob syntax has the > added benefit of congruity with Xapian wildcard syntax. This naturally > leads to a rooted, non-recursive syntax by default (like globs), where a > * at the end means recursive and a * at the beginning means non-rooted. > In fact, we could easily generalize this to arbitrary shell globs. I agree with all of this. Something like fnmatch() sounds appropriate to me. In fact, I'd suggest that we implement this very much like fnmatch() with folder references like paths -- where "/" is always the separator, regardless of how things are handled in the underlying storage. So depending on the backend, foo/bar could refer to "Maildir/foo/bar" or "Maildir/.foo.bar". And personally, I think I'd prefer that folder: be anchored by default, so that folder:work means "the top-level folder named work", but it's not a big deal to me as long as there's a fairly easy way to specify exactly what I want. -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4