Re: [PATCH 2/5] test: fix insert folder: searches

[Rob Browning <rlb@defaultvalue.org>]

Austin Clements <amdragon@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