Re: proposing "notmuch purge"

[Daniel Kahn Gillmor <dkg@fifthhorseman.net>]

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

On Tue 2020-01-14 07:01:08 +0200, Teemu Likonen wrote:
> We would need "notmuch search --exclude=false tag:deleted" to really
> find all messages with tag:deleted.

I agree that we ought to deliberately avoid the exclude_tags when
purging.

> I think that the "SEARCH-TERMS" part should be configurable, not
> hard-coded. A user could have setting like
> "search.purge_tags=deleted;spam" and that would lead to search terms
> "tag:deleted OR tag:spam" in the purge operation.

I want the user to be able to run "notmuch purge", with no arguments, to
"Do What I Mean"™

I also want the "purge" subcommand to have its own configuration
space -- it's *not* a specialized form of "search".

So if we choose to make it configurable, i have two (mutually-exclusive)
counter-proposals to yours above.  In either case, if the user supplies
search terms, they are used instead of pulling from the config

a) the config variable is "purge.tags", and by default (if no setting is
   present) its value is "deleted".  "notmuch purge" with no search
   terms expands this value into a tags-based selection.

b) "notmuch purge" with no search terms looks for a special stored query
   named "query.purge".  If that is not present, it uses "tags:deleted".

(b) is slightly more flexible than (a), in that the user can configure
it to use arbitrary queries, not just tags, though both behave
identically in a default (not-explicitly-configured) setup.

fwiw, i'd also like to consider exposing this functionality from
libnotmuch, not just from the cli (so that it can be used by MUAs that
are based solely on the library), but if there are good arguments for
avoiding this in the library, i'd be happy to hear them.

            --dkg


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]