d6/547fbee9541946b078ccbb0981c7352a924937

   1 Return-Path: <cworth@cworth.org>\r
   2 X-Original-To: notmuch@notmuchmail.org\r
   3 Delivered-To: notmuch@notmuchmail.org\r
   4 Received: from localhost (localhost [127.0.0.1])\r
   5         by olra.theworths.org (Postfix) with ESMTP id 3FC7B431FBD;\r
   6         Thu,  3 Dec 2009 22:18:02 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 Received: from olra.theworths.org ([127.0.0.1])\r
   9         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  10         with ESMTP id Tg6tEaokCmpH; Thu,  3 Dec 2009 22:18:01 -0800 (PST)\r
  11 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  12         by olra.theworths.org (Postfix) with ESMTP id 3EEC9431FAE;\r
  13         Thu,  3 Dec 2009 22:18:01 -0800 (PST)\r
  14 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  15         id D9A4E2542FB; Thu,  3 Dec 2009 22:18:00 -0800 (PST)\r
  16 From: Carl Worth <cworth@cworth.org>\r
  17 To: Marten Veldthuis <marten@veldthuis.com>, notmuch <notmuch@notmuchmail.org>\r
  18 In-Reply-To: <1259830240-sup-2467@gopher.local>\r
  19 References: <1259100630-13673-1-git-send-email-jan@ryngle.com>\r
  20         <87ws1583ea.fsf@yoom.home.cworth.org>\r
  21         <1259830240-sup-2467@gopher.local>\r
  22 Date: Thu, 03 Dec 2009 22:17:52 -0800\r
  23 Message-ID: <87r5rbfejz.fsf@yoom.home.cworth.org>\r
  24 MIME-Version: 1.0\r
  25 Content-Type: multipart/signed; boundary="=-=-=";\r
  26         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  27 Subject: Re: [notmuch] [PATCH 0/4] Make tags applied by 'notmuch new'\r
  28  configurable.\r
  29 X-BeenThere: notmuch@notmuchmail.org\r
  30 X-Mailman-Version: 2.1.12\r
  31 Precedence: list\r
  32 List-Id: "Use and development of the notmuch mail system."\r
  33         <notmuch.notmuchmail.org>\r
  34 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  35         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  36 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  37 List-Post: <mailto:notmuch@notmuchmail.org>\r
  38 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  39 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  40         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  41 X-List-Received-Date: Fri, 04 Dec 2009 06:18:02 -0000\r
  42 \r
  43 --=-=-=\r
  44 Content-Transfer-Encoding: quoted-printable\r
  45 \r
  46 On Thu, 03 Dec 2009 10:48:00 +0100, Marten Veldthuis <marten@veldthuis.com>=\r
  47  wrote:\r
  48 > I can see one clear case where that would become a problem: mistaggings.\r
  49 > If I set up something so that in 99% of the cases, it'd tag new mail\r
  50 > correctly with say "inbox unread mytag", I could quickly pick the\r
  51 > mistagged ones out and remove the offending tag.=20\r
  52 >=20\r
  53 > If you do it like above however, the autotag script would come merrily\r
  54 > along and retag them.\r
  55 \r
  56 Right. A fully automatic, rule-based tag does not allow for manual\r
  57 deletion of the exact same tag, (nor even manual addition).\r
  58 \r
  59 I've given this some thought and there are things we could do here. For\r
  60 example, the automatic tag could be stored internally under a different\r
  61 prefix than the manual tag of the same name. That would be enough to\r
  62 support the manual addition of a tag, such that a user-level search such\r
  63 as:\r
  64 \r
  65         tag:foo\r
  66 \r
  67 would map internally to something like:\r
  68 \r
  69         (auto-tag:foo OR manual-tag:foo)\r
  70 \r
  71 Then manual tag removal could similarly be stored as yet anther internal\r
  72 prefix that would work in a negative sense. So the search for "tag:foo"\r
  73 would now map to:\r
  74 \r
  75         ((auto-tag:foo OR manual-tag:foo) AND NOT manual-tag-removal:foo) [*]\r
  76 \r
  77 I'm not sure yet if this idea is simply clever or insanely stupid.\r
  78 \r
  79 It does seem like we could do this and hide all of the complexity\r
  80 entirely from the user. But hidden complexity can raise its head in\r
  81 nasty ways. Such as "I wrote this rule in my configuration file, why\r
  82 isn't it working?" (in the face of a hidden manual-tag-removal).\r
  83 \r
  84 Another idea would be to just keep the rule-based tags strictly as\r
  85 configured, explicitly prevent the user from manually adding/removing\r
  86 tags of the same name. And then the user could play games like the above\r
  87 in saved searches to be able to simulate manual touchups of rule-based\r
  88 tags, (without the automatic vs. manual state being hidden).\r
  89 \r
  90 Yet another idea is to keep all rule-based tagging out of the\r
  91 configuration, and let the user come up with whatever scheme they most\r
  92 prefer. This could still allow for the configuration to hold saved\r
  93 searches, (which could stand in for rule-based tags in a lot of cases\r
  94 and avoid a lot of the complexity discussed here).\r
  95 \r
  96 So those are some of my current thoughts on the issue. And that's why I\r
  97 haven't put any auto tagging into the configuration file yet.\r
  98 \r
  99 =2DCarl\r
 100 \r
 101 [*] Or should that be:\r
 102 \r
 103         (manual-tag:foo OR (auto-tag:foo AND NOT manual-tag-removal:foo))\r
 104 \r
 105 It probably wouldn't matter in practice as presumably the addition of\r
 106 the manual-tag would remove any manual-tag-removal and vice-versa.\r
 107 \r
 108 --=-=-=\r
 109 Content-Type: application/pgp-signature\r
 110 \r
 111 -----BEGIN PGP SIGNATURE-----\r
 112 Version: GnuPG v1.4.10 (GNU/Linux)\r
 113 \r
 114 iD8DBQFLGKmR6JDdNq8qSWgRAjfQAKCZxDDviUDd60PeVKyJkGoowEgYsACfeD6b\r
 115 vz0M9K47VlX2UiIGcRHa2hQ=\r
 116 =3KPT\r
 117 -----END PGP SIGNATURE-----\r
 118 --=-=-=--\r