From: Carl Worth <cworth@cworth.org>
To: Dirk Hohndel <hohndel@infradead.org>,
	Sebastian Spaeth <Sebastian@SSpaeth.de>,
	Notmuch developer list <notmuch@notmuchmail.org>
Subject: Re: notmuchsync: handling of the deleted tag
In-Reply-To: <m34obmdzjj.fsf@x201s.gr8dns.org>
References: <87bp7vewa5.fsf@raven.defaultvalue.org>
 <87mxrcsb8a.fsf@SSpaeth.de>	<87r5gnomt2.fsf@raven.defaultvalue.org>
	<87hbfnmiux.fsf@yoom.home.cworth.org>	<87oc9vf17n.fsf@SSpaeth.de>
 <m34obmdzjj.fsf@x201s.gr8dns.org>
User-Agent: Notmuch/0.4 (http://notmuchmail.org) Emacs/23.2.1
	(i486-pc-linux-gnu)
Date: Fri, 12 Nov 2010 16:52:51 -0800
Message-ID: <87pqua82os.fsf@yoom.home.cworth.org>
MIME-Version: 1.0
Content-Type: multipart/signed; boundary="=-=-=";
	micalg=pgp-sha1; protocol="application/pgp-signature"
Precedence: list

--=-=-=
Content-Transfer-Encoding: quoted-printable

On Fri, 12 Nov 2010 13:04:16 -0800, Dirk Hohndel <hohndel@infradead.org> wr=
ote:
> > notmuchsync. Seriously, what does notmuchsync still provide that notmuch
> > cannot do? I wonder if I shouldn't stick a "deprecated" warning on it.
>=20
> Please don't! I use it all the time:

Excellent. I love getting more feedback from users so that we can
understand things better.

> I use it to archive mail that I don't want on an imap server any more,
> but in a local maildir. Can't do that with notmuch.

Can you describe this use case in a bit more detail? I'd like to
understand what needs to be done to support this.

> I use it to prune mail that has the deleted tag. Again not something
> that notmuch supports.

This one is a simple one-liner as of notmuch 0.4:

    notmuch search --output=3Dfiles tag:deleted -print0 | xargs -0 rm

And that's something we could even add to a keybinding in the emacs
interface[*].

Meanwhile, I know people have asked for keybindings to even just add the
"deleted" tag before. What I still want for that is good support for
being able to configure tags that cause mails to be automatically
omitted from search results---unless the user is explicitly searching
for mails with that tag. So for example, I would add "deleted" and
"spam" to such a list and never see mails with that tag unless I go
looking for a mis-tagged email with a search like "from:someone and
tag:spam".

I think the above should be fairly easy. One way to do it is to just
implicitly add "and not (tag:deleted or tag:spam)" to all searches. And
then simply omit the relevant portion of this if the original search
terms happen to mention tag:deleted or tag:spam. This is what sup does,
for example.

=2DCarl

[*] Personally, I don't want a keybinding for actual deletion of mail
files. As long as nothing appears in searches, then I'd prefer the
tagged messages not be deleted right away. Instead, I'd like a cron job
to delete appropriately tagged messages after some safety interval (a
month, say). For that, I'd like better support for specifying message
dates of course, (that's been on my todo list for some time). But
really, I care about the date of the tag, not the date of the
message. We don't save information like that, but the cron script could
do something cheesy like implement counters in tags:

  # XXX: Entirely untested!

  # Days after a mail is tag:deleted when the mail will be deleted
  EXPIRATION=3D30
  for days in $(seq 0 $((EXPIRATION - 1))); do
    notmuch tag +expire-$((days)) -expire-$((days + 1)) tag:expire-$(days +=
 1))
  done

  notmuch search --output=3Dfiles tag:expire-0 and tag:deleted -print0 | xa=
rgs -0 rm
  notmuch tag -expire-0 tag:expire-0

  notmuch tag +expire-$EXPIRATION +expiring tag:deleted and not tag:expiring
  notmuch tag -expiring not tag:deleted

OK. Looking at that---that's *really* cheesy. Perhaps we should come up
with a sane way to do this. Hooks on the addition or deletion of the
"deleted" tag that set/cleared a date value in the message document in
the database might be much cleaner.

But the above might actually work for now. Anyone brave enough to test
it?

=2D-=20
carl.d.worth@intel.com

--=-=-=
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)

iD8DBQFM3eFj6JDdNq8qSWgRAuxSAJ96voAudHOJQNe1pMpfp02iydOBzgCgoH3V
la+asnmRbd7AOdTao2yjEes=
=mGIG
-----END PGP SIGNATURE-----
--=-=-=--