Hi Carl - On Tue, 06 May 2014, Carl Worth <cwo...@cworth.org> wrote: > dm-list-email-notm...@scs.stanford.edu writes: >> However, currently it seems strange that there are *two* different >> search terms (folder and path), and that neither one lets you search for >> a portion of your folder name. > > For what it's worth, I totally agree. I'm guilty as far as sitting out > of the detailed design discussions, (I don't use any sort of > folder-based searching, so I don't care too much). I was aware of the > problems of the original "folder:" code I wrote, and I was happy to hear > that people were addressing those problems. > > But it's terribly strange to me that notmuch now has two different > search terms that overlap so much in functionality. I know that I will > never trust myself to be able to distinguish/describe the folder: > vs. path: semantics without consulting the documentation. And that's > discouraging.
The discussions about this were lengthy and tedious, and I was glad we eventually reached some consensus about what we wanted. It's always disappointing to find out one hasn't found the solution to satisfy everyone, but in the end I think I'm happier we were able to reach a decision, do something about the real issues people were facing with folder: and move on, rather than just grind to a halt. I think we were pretty close to everyone just dropping the ball and letting the folder: prefix be, warts and all. The idea of path: is that it's the exact filesystem directory, relative from the maildir root, with an rsync like ** syntax for recursive matching. Turns out people want folder: to hide maildir implementation details like cur and new. These are not compatible, or you need to add a syntax that's not easy or discoverable. path: is now pretty much complete, and allows one to do robust scripting that won't break in surprising ways. folder: is something we can still add new functionality into, for example fancier interpretations of maildir++, or anchoring if we ever get the custom query parser. > I think the original "folder:" shortcomings could have been addressed > without adding two terms, and also without losing some functionality, > (as shown in David's use case). > > I would have liked to have seen some explicit syntax for anchoring the > beginning and end of the directory name, (which could have then been > re-used for anchoring subject: or even some future header: prefix). As I understood it, that would have required writing a custom query parser, a significant effort. At least nobody came up with a scheme to do the anchoring without the parser while addressing the other issues with the old folder: prefix. > I've always thought that the "cur" and "new" directories were somewhere > on the spectrum between pointless and annoying. The idea with the > original "folder:" indexing was to implicitly ignore these, (when both > existed). > > It seems that the new "folder:" continues this idea, while the new > "path:" does not. Correct. > Meanwhile, the new "folder:" anchors the search to the beginning of > the directory, while "path:" does not. Incorrect (or I don't understand you). > And finally, "path:" adds a magic syntax to do hierarchical matching > while "folder:" does not. Correct. > That's an odd hodgepodge of non-orthogonal distinction in > functionality. I'm sorry to hear you think that way. One is verbatim filesystem path, the other hides mail store folder implementation details as a convenience. BR, Jani. _______________________________________________ notmuch mailing list notmuch@notmuchmail.org http://notmuchmail.org/mailman/listinfo/notmuch