On Fri, 24 Jan 2014, Austin Clements <aclements@csail.mit.edu> wrote: > On Thu, 09 Jan 2014, Jani Nikula <jani@nikula.org> wrote: >> Hi all, this series makes the folder: search prefix literal, or switches >> it from a probabilistic prefix to a boolean prefix. With this, you have >> to give the path from the maildir root to the folder you want in full, >> including the maildir cur/new component, if any. Examples: > > I strongly disagree with requiring the cur/new component. The cur/new > directory is an internal implementation detail of Maildir (and a rather > broken one at that) and no more a part of the "folder" of a piece of > mail than its final file name component. It's also the less obvious > user interface; if we require the cur/new component, we *will* get > people asking why their folder searches aren't working, but if we strip > the cur/new component, nobody will be surprised. > > I think the question is not whether we should strip cur/new, but when. > We've already defined a "_filename_is_in_maildir" test in > lib/message.cc, which we depend on for flag sync. It's simple, but I > think this would be the right thing to use for consistency. I'd like to discuss some of the reasons I chose to include the cur/new components. Admittedly, none of them are very strong on their own, but all of them together tilted my opinion towards requiring them. The way I see it, notmuch supports maildir, but does not require it. In many ways the messages are just files somewhere in the directory hierarchy. There are only a few cases where it matters that there are cur/new/tmp directories within a directory. If you strip cur and new, it becomes impossible to distinguish between files in foo, foo/cur, and foo/new - and one of the reasons for changing folder: in the first place is to be able to better distinguish between folders. Apparently mutt presents the difference between messages in new and cur to its users (so I've been told; I've never really used mutt), and our integration with mutt lacks that distinction. We could fix that by requiring the cur/new components in folder: searches. Speaking of consistency, compare _filename_is_in_maildir() with _entries_resemble_maildir() in notmuch-new.c. What should the indexed folder: prefix be if there is not all of cur, new, and tmp? We will actually index files in tmp if cur or new is not present! What if the missing sibling directories are added (or existing ones removed) later? Where's the consistency compared to new.ignore config, which also matches the cur/new components if so desired? Or consistency with notmuch search --output=files? My conclusion was that requiring *all* filesystem folder components as-is is consistent, most versatile, agnostic to Maildir or Maildir++ implementation details wrt directory naming or hierarchy, without difficult corner cases, simplest to implement, and unsurprising (once you understand the cur/new distinction). For *me* this is the more obvious user interface. And hey, I'm a user too. Perhaps we need to have two prefixes, one of which is the literal filesystem folder and another which hides the implementation details, like I mentioned in my mail to Peter [1]. But consider this: my proposed implementation does cover *all* use cases. BR, Jani. [1] id:8761ppurfz.fsf@nikula.org