aa/d53baab548dea9caae7abf284609102f3a3feb

   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 B26684196F4\r
   6         for <notmuch@notmuchmail.org>; Wed, 14 Apr 2010 17:59:02 -0700 (PDT)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -2.89\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-2.89 tagged_above=-999 required=5\r
  12         tests=[ALL_TRUSTED=-1, BAYES_00=-1.9, T_MIME_NO_TEXT=0.01]\r
  13         autolearn=ham\r
  14 Received: from olra.theworths.org ([127.0.0.1])\r
  15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  16         with ESMTP id rsp1aS65P1n0; Wed, 14 Apr 2010 17:59:01 -0700 (PDT)\r
  17 Received: from yoom.home.cworth.org (localhost [127.0.0.1])\r
  18         by olra.theworths.org (Postfix) with ESMTP id 81EB7431FC1;\r
  19         Wed, 14 Apr 2010 17:59:01 -0700 (PDT)\r
  20 Received: by yoom.home.cworth.org (Postfix, from userid 1000)\r
  21         id 2D232568DE1; Wed, 14 Apr 2010 17:59:01 -0700 (PDT)\r
  22 From: Carl Worth <cworth@cworth.org>\r
  23 To: Xavier Maillard <xma@gnu.org>, Mark Anderson <MarkR.Anderson@amd.com>,\r
  24         Jesse Rosenthal <jrosenthal@jhu.edu>,\r
  25         "notmuch\@notmuchmail.org" <notmuch@notmuchmail.org>\r
  26 Subject: Re: [notmuch] Bulk message tagging\r
  27 In-Reply-To: <m2wrwf76n3.fsf@deb.maillard.im>\r
  28 References: <m2tyrrkf32.fsf@deb.maillard.im> <87sk7b30tg.fsf@jhu.edu>\r
  29         <m2bpdye86s.fsf@deb.maillard.im>\r
  30         <3wdmxxg4axm.fsf@testarossa.amd.com>\r
  31         <m2wrwf76n3.fsf@deb.maillard.im>\r
  32 Date: Wed, 14 Apr 2010 17:59:01 -0700\r
  33 Message-ID: <87fx2xfs4q.fsf@yoom.home.cworth.org>\r
  34 MIME-Version: 1.0\r
  35 Content-Type: multipart/signed; boundary="=-=-=";\r
  36         micalg=pgp-sha1; protocol="application/pgp-signature"\r
  37 X-BeenThere: notmuch@notmuchmail.org\r
  38 X-Mailman-Version: 2.1.13\r
  39 Precedence: list\r
  40 List-Id: "Use and development of the notmuch mail system."\r
  41         <notmuch.notmuchmail.org>\r
  42 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  43         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  44 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  45 List-Post: <mailto:notmuch@notmuchmail.org>\r
  46 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  47 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  48         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  49 X-List-Received-Date: Thu, 15 Apr 2010 00:59:02 -0000\r
  50 \r
  51 --=-=-=\r
  52 Content-Transfer-Encoding: quoted-printable\r
  53 \r
  54 On Sat, 10 Apr 2010 15:56:48 +0200, Xavier Maillard <xma@gnu.org> wrote:\r
  55 > On Tue, 6 Apr 2010 13:51:01 -0600, Mark Anderson <MarkR.Anderson@amd.com>=\r
  56  wrote:\r
  57 > >=20\r
  58 > > I think that '*' is definitely an awesome command, but I wonder if we\r
  59 > > shouldn't have another command for the notmuch-search buffer which means\r
  60 > > 'tag all the threads that I can see in this buffer'.\r
  61 >=20\r
  62 > This is exactly what my initial post asked for. '*' is not\r
  63 > totally satisfying for me due to the "limitations" you\r
  64 > exposed. Though It is a good and acceptable workaround for me.\r
  65 > As said, I just have to pay attention to redo my search query\r
  66 > before pressing the '*' key.\r
  67 \r
  68 The other bug with "*" is that it doesn't give any visual feedback, (the\r
  69 tag addition/deletion doesn't show up).\r
  70 \r
  71 We could fix all[*] the bugs of "*" by changing it to simply call the\r
  72 new region-based tagging function. The only concern I have with that is\r
  73 that it might be significantly slower, (it will execute N "notmuch tag"\r
  74 commands to tag the N threads in the current buffer, rather than just\r
  75 one "notmuch tag" command with the same search).\r
  76 \r
  77 But the command-line based "notmuch tag +/-<tag> <search>" will always\r
  78 still be available for true "bulk" tagging, so maybe having "*" in emacs\r
  79 be implemented the slower way would be fine.\r
  80 \r
  81 I think the biggest concern I have with the performance is that if it\r
  82 *is* too slow, then the user might interrupt it with emacs, and with the\r
  83 current implementation that would lead to inconsistent display. That's\r
  84 not specific to "*" though---that's a bug with the current region-based\r
  85 implementation---it's just that "*" might make it much easier to hit.\r
  86 \r
  87 =2DCarl\r
  88 \r
  89 [*] Most all the bugs, at least. Even just a simple 'a' (or '+' or '-')\r
  90 on a single thread is already doing something subtly different than it\r
  91 should. It's tagging all messages in the thread, but that might be more\r
  92 messages than existed when the thread-summary was created. So you might\r
  93 see:\r
  94 \r
  95         [1/1] A. Bozo                           Boring topic...\r
  96 \r
  97 and decide to archive the thread, and never realize that what you\r
  98 archived away was several messages that would have been displayed as:\r
  99 \r
 100         [3/3] A Bozo, B Wizard, C Wizard        Boring topic... [**]\r
 101 \r
 102 if you had only refreshed first.\r
 103 \r
 104 So we really should fix that bug and only manipulate messages that were\r
 105 actually present when the search was performed. Note that 'a' inside of\r
 106 the show view does not have this bug---it does only affect messages\r
 107 displayed.\r
 108 \r
 109 I'm not currently afflicted by this bug only because I'm running\r
 110 "notmuch new" manually, before mail-reading sessions as opposed to\r
 111 inside a cron-job or similar.\r
 112 \r
 113 [**] This is similar to the "thread pattern" idea described by Joey Hess\r
 114 here:\r
 115 \r
 116         http://kitenet.net/~joey/blog/entry/thread_patterns/\r
 117 \r
 118 Our current one-line presentation of threads does a really lousy job of\r
 119 letting the user see thread patterns like this. We should perhaps come\r
 120 up with something better.\r
 121 \r
 122 One "something better" I have in mind would be the ability to write\r
 123 searches that could identify and tag threads according to these\r
 124 patterns. Our current search syntax isn't powerful enough to express\r
 125 these kinds of relations about messages within threads, but I would be\r
 126 very interested in coming up with something that does.\r
 127 \r
 128 The parts that Xapian can't easily support here probably wouldn't have\r
 129 to be fast either---they could operate on the results of threads, which\r
 130 are generally "small". At least, I hope nobody has threads with hundreds\r
 131 of thousands of messages in them.\r
 132 \r
 133 --=-=-=\r
 134 Content-Type: application/pgp-signature\r
 135 \r
 136 -----BEGIN PGP SIGNATURE-----\r
 137 Version: GnuPG v1.4.10 (GNU/Linux)\r
 138 \r
 139 iD8DBQFLxmTV6JDdNq8qSWgRAqknAJ9KMitIGmBD99B0VbdG7gor/UPcGACdHe01\r
 140 pziYmg6vsrSz+nC7sNaiMMs=\r
 141 =ub9H\r
 142 -----END PGP SIGNATURE-----\r
 143 --=-=-=--\r