proposing "notmuch purge"

[Antoine Beaupré]

On 2020-01-13 17:28:38, Daniel Kahn Gillmor wrote:
> This e-mail proposes a new notmuch subcommand "purge", which actually
> removes explicitly deleted messages from the mailstore.
>
> Notmuch currently never deletes mail, but notmuch-emacs makes it easy to
> tag mail with "deleted" (via the "d") key, and "notmuch setup"
> automatically adds "deleted" to the search.exclude_tags setting.
>
> Users typically do actually want to delete messages, and they want them
> gone from their filesystem and from the index.

I certainly do! :)

> while everyone who has used notmuch for a while probably has a clever
> way of doing this, those techniques are all probably slightly different
> (and possibly buggy), and the cognitive burden of figuring out how to do
> this sensibly for new users seems like something we should avoid.

Agreed.

> So i'm proposing "notmuch purge", which could be something as simple as
> the equivalent of:
>
>    notmuch search --output=files --format=text0 tag:deleted | \
>       xargs --null --no-run-if-empty rm && \
>          notmuch new --no-hooks
>
> (credit for the pipeline above goes to anarcat, in Cc; i added the
> "notmuch new --no-hooks" part, because i would want the items gone from
> the db as well)

I don't quite understand that last bit. I deliberately do *not* run
notmuch-new in my notmuch-purge script:

https://gitlab.com/anarcat/scripts/blob/master/notmuch-purge

... because it's setup as a pre-new hook, so it runs right before
new. So it doesn't need to call new.

> If i was to implement this, i'd probably implement it directly in C, not
> as a shell script, because this lets us drop messages from the db as we
> unlink() the files.

I also agree it might be faster than forking like crazy and rescanning
the entire DB.

But maybe we can just start with a shell wrapper for now. That's how
many git subcommands start, by the way, and it might just be "good
enough" for most people.

> Inevitably, someone will come up with some more clever
> options/generalizations (i can already think of at least one), but if we
> have a particular implementation to hang these proposals on, it should
> help us to build something sensibly robust with a wider consensus, and
> new users can pick up and use that functionality easily/safely/with
> confidence.
>
> I note that this is a divergence from the historical expectation of
> having all "notmuch" subcommands not directly tamper with the
> mailstore.  I think given the context that divergence is OK.

Well, we're already tampering with the mailstore: we're changing flags!
:)

> Any objections to this approach?

Not from me, I've been advocating for data destruction for years
now. Happy to get one more on my crew! ;)

A.

-- 
People arbitrarily, or as a matter of taste, assigning numerical values
to non-numerical things. And then they pretend that they haven't just
made the numbers up, which they have. Economics is like astrology in
that sense, except that economics serves to justify the current power
structure, and so it has a lot of fervent believers among the powerful.
                        - Kim Stanley Robinson, Red Mars