Austin Clements <amdragon at MIT.EDU> writes: > This is the other reason I disagree with including cur/new. If we strip > it, people's existing folder: searches will mostly continue to work. If > we include it, such saved searches, scripted searches, and post-new > hooks are guaranteed to break.
What about Maildir++'s ".folder" vs an mh (or other) "folder"? And it might be deemed unimportant, but always unifying cur/new will make it impossible for someone not using Maildir to independently refer to legitimate directories named cur and new. If it were feasible to rewrite queries, I'd be tempted to consider adding a fully literal path:, and then building a "more magic" maildir: or folder: on top, via rewriting. Regardless, I suspect that in the long run it might make sense to support literal searches somehowm, in addition to any more "friendly" option (that perhaps guesses about the mailstore type, etc.). One possibility might be to change the current literal folder: proposal to present itself as path: (leaving folder: alone). Then any rework of folder: (as the friendlier term) could be considered independently. But I don't feel very strongly about any of this. I'll be happy with any reasonable way to specify specific "folders" in a Maildir++ tree (with or without cur/new unification, etc.). Thanks -- Rob Browning rlb @defaultvalue.org and @debian.org GPG as of 2011-07-10 E6A9 DA3C C9FD 1FF8 C676 D2C4 C0F0 39E9 ED1B 597A GPG as of 2002-11-03 14DD 432F AE39 534D B592 F9A0 25C8 D377 8C7E 73A4