On Wed, 24 Feb 2010 11:28:29 -0800, Carl Worth <cworth@cworth.org> wrote: > On Wed, 24 Feb 2010 14:01:18 -0500, Jameson Rollins <jrollins@finestructure.net> wrote: > > > 2. It removes the "inbox" and "unread" tags while adding the tag to > > > indicate deletion. > > > > Hey, Carl. Why is this last point important? > > I guess I was imagining the case of running "notmuch search tag:inbox" > at the command-line. That output will get out of hand fairly quickly if > it includes all deleted messages back to the beginning of time, (or as > far back as the window of actually deleting files from the > mailstore[*]). > > But you're right that tags should really be handled orthogonally. Maybe > what we want is lower-level support for the "deleted" tag? Other than > just the high-level emacs interface? Yeah, I tend to think that notmuch should be as agnostic about tag handling as possible. The beauty of that is that it keeps things as simple and configurable as possible, which is necessary because everyone will have a different way they want to do things. The point of the functions provided by these patches is basically just convenience. In fact, I had implemented the functions I previously included in my own private .el, since I didn't know if they would be wanted by all others. In general, I'm a big fan of "keep it simple" (KIS). In this case that means "if I want to add a delete tag, the tool should do just that and nothing else". I certainly don't want the other tags modified. If one did, it's really quite easy to write custom emacs functions to do that. We can just hints on doing that in the wiki if need be. > That could put *more* direct interpretation of specific tags in the low > levels. And this is the opposite direction of where we've been going (or > talking about at least). We've currently got "inbox" and "unread" inside > the low levels and there's been talking or removing those, switching to > just "new" or making it all configurable. This isn't a bad idea at all. I don't think it changes the functionality much, but it does make things conceptually much simpler, which I'm always in favor of (KIS). jamie.