Austin Clements writes:
> However, it seems like this is overloading one prefix for two
> meanings.
Oh, and I agree here. I think that ideally, there would be at least one
very-literal way to identify a specific directory (or tree, perhaps via
**), and then some other less-precise, but more fri
Austin Clements writes:
> folder: could work the way I suggested (simply the path to the file,
> with {cur,new} stripped off).
Hmm, so would notmuch try to guess whether or not it's dealing with a
maildir++ tree, and if so convert folder:foo to a search of .foo, and/or
folder:foo/bar to .foo.bar
Austin Clements writes:
> However, it seems like this is overloading one prefix for two
> meanings.
Oh, and I agree here. I think that ideally, there would be at least one
very-literal way to identify a specific directory (or tree, perhaps via
**), and then some other less-precise, but more fri
Austin Clements writes:
> folder: could work the way I suggested (simply the path to the file,
> with {cur,new} stripped off).
Hmm, so would notmuch try to guess whether or not it's dealing with a
maildir++ tree, and if so convert folder:foo to a search of .foo, and/or
folder:foo/bar to .foo.bar
