Re: [PATCH] add notmuch-show-delete keybinding 'd'

[Carl Worth <cworth@cworth.org>]

[-- Attachment #1: Type: text/plain, Size: 2243 bytes --]

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?

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.

I do know that I also want to have low-level support for "muted" (aka
"killed" threads). For that I want an --exclude option to notmuch search
that would look something like this:

notmuch search --exclude="<negative-search-terms>" <positive-search-terms>

Where the result would be the set difference of the threads matched by
the two sets of search terms. Perhaps with something like that in place
all we'd want in addition would be a configuration option to add
--exclude=tag:muted by default. And if we go that route, perhaps we
could have an option for an implicit "and not tag:deleted" for the
search terms as well.

I do worry about making the command-line tool hard to use without a
configuration file, but it also seems very appealing to keep the lowest
levels very general to allow people to experiment with whatever they
want on top.

-Carl

[*] My eventual plan for detected spam and manually deleted messages is
to keep them in the mail store so they are searchable for some time (a
month or two) and then deleting them after that (with something like a
cron job using a convenient --before="2 months ago" syntax to a notmuch
search command).

[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]