Re: proposing "notmuch purge"
Teemu Likonen [2020-01-14T07:01:08+02] wrote: > notmuch search --exclude=false --output=files \ > --format=text0 SEARCH-TERMS > > I think that the "SEARCH-TERMS" part should be configurable, not > hard-coded. Obviously there is no need for configuration if purging is just a command that user runs manually or in his own scripts: "notmuch purge SEARCH-TERMS". Configuration is needed if some (mail client) operation does purging automatically. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tliko...@iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: proposing "notmuch purge"
Daniel Kahn Gillmor [2020-01-13T17:28:38-05] wrote: > 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 agree with the proposal but I would like to add one important point to the discussion and semantics. If the implementation goes through "notmuch search" we should understand what search.exclude_tags does. Let's say a user has this settings: "search.exclude_tags=deleted;spam". Then "notmuch search tag:deleted" will not find messages which have both of the excluded tags, "deleted" and "spam". We would need "notmuch search --exclude=false tag:deleted" to really find all messages with tag:deleted. So here's the search semantics I propose: notmuch search --exclude=false --output=files \ --format=text0 SEARCH-TERMS 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. -- /// OpenPGP key: 4E1055DC84E9DFF613D78557719D69D324539450 // https://keys.openpgp.org/search?q=tliko...@iki.fi / https://keybase.io/tlikonen https://github.com/tlikonen signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
Re: proposing "notmuch purge"
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 ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
proposing "notmuch purge"
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. 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. 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) 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. 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. Any objections to this approach? --dkg signature.asc Description: PGP signature ___ notmuch mailing list notmuch@notmuchmail.org https://notmuchmail.org/mailman/listinfo/notmuch
