fa/4c80dff5ff31f1edece82b5349eeac7a98168a

   1 Return-Path: <m.walters@qmul.ac.uk>\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 27A94431FC3\r
   6         for <notmuch@notmuchmail.org>; Wed, 23 Oct 2013 02:57:15 -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: 1.401\r
  10 X-Spam-Level: *\r
  11 X-Spam-Status: No, score=1.401 tagged_above=-999 required=5\r
  12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
  13         FREEMAIL_REPLY=2.499, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3]\r
  14         autolearn=disabled\r
  15 Received: from olra.theworths.org ([127.0.0.1])\r
  16         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  17         with ESMTP id OYHn-KWMPLw8 for <notmuch@notmuchmail.org>;\r
  18         Wed, 23 Oct 2013 02:57:07 -0700 (PDT)\r
  19 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
  20         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
  21         (No client certificate requested)\r
  22         by olra.theworths.org (Postfix) with ESMTPS id E47A1431FBC\r
  23         for <notmuch@notmuchmail.org>; Wed, 23 Oct 2013 02:57:06 -0700 (PDT)\r
  24 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
  25         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
  26         (envelope-from <m.walters@qmul.ac.uk>)\r
  27         id 1VYvBU-0000Je-TY; Wed, 23 Oct 2013 10:57:01 +0100\r
  28 Received: from 93-97-24-31.zone5.bethere.co.uk ([93.97.24.31] helo=localhost)\r
  29         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.71)\r
  30         (envelope-from <m.walters@qmul.ac.uk>)\r
  31         id 1VYvBU-0008GN-FY; Wed, 23 Oct 2013 10:57:00 +0100\r
  32 From: Mark Walters <markwalters1009@gmail.com>\r
  33 To: Austin Clements <amdragon@MIT.EDU>\r
  34 Subject: Re: [PATCH 0/8] Improve tag change completion\r
  35 In-Reply-To: <20131023001952.GD20337@mit.edu>\r
  36 References: <1382471457-26056-1-git-send-email-amdragon@mit.edu>\r
  37         <87mwm1x9pi.fsf@qmul.ac.uk> <20131023001952.GD20337@mit.edu>\r
  38 User-Agent: Notmuch/0.16 (http://notmuchmail.org) Emacs/23.4.1\r
  39         (x86_64-pc-linux-gnu)\r
  40 Date: Wed, 23 Oct 2013 10:56:59 +0100\r
  41 Message-ID: <87fvrsxqc4.fsf@qmul.ac.uk>\r
  42 MIME-Version: 1.0\r
  43 Content-Type: text/plain; charset=us-ascii\r
  44 X-Sender-Host-Address: 93.97.24.31\r
  45 X-QM-SPAM-Info: Sender has good ham record.  :)\r
  46 X-QM-Body-MD5: 53d34e767f2e822206602c3a48c58069 (of first 20000 bytes)\r
  47 X-SpamAssassin-Score: 0.6\r
  48 X-SpamAssassin-SpamBar: /\r
  49 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
  50         determine if it is\r
  51         spam. We require at least 5.0 points to mark a message as spam.\r
  52         This message scored 0.6 points. Summary of the scoring: \r
  53         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
  54         provider *      (markwalters1009[at]gmail.com)\r
  55         *  1.0 FREEMAIL_REPLY From and body contain different freemails\r
  56         * -0.4 AWL AWL: From: address is in the auto white-list\r
  57 X-QM-Scan-Virus: ClamAV says the message is clean\r
  58 Cc: notmuch@notmuchmail.org\r
  59 X-BeenThere: notmuch@notmuchmail.org\r
  60 X-Mailman-Version: 2.1.13\r
  61 Precedence: list\r
  62 List-Id: "Use and development of the notmuch mail system."\r
  63         <notmuch.notmuchmail.org>\r
  64 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  65         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  66 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  67 List-Post: <mailto:notmuch@notmuchmail.org>\r
  68 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  69 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  70         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  71 X-List-Received-Date: Wed, 23 Oct 2013 09:57:15 -0000\r
  72 \r
  73 \r
  74 Hi\r
  75 \r
  76 On Wed, 23 Oct 2013, Austin Clements <amdragon@MIT.EDU> wrote:\r
  77 > Quoth Mark Walters on Oct 22 at 10:43 pm:\r
  78 >> This looks good to me +1. It makes the code clearer and nicer to read as\r
  79 >> well as giving a better user experience, and it is makes fixing the long\r
  80 >> standing tagging races simpler.\r
  81 >> \r
  82 >> I have a couple of docstring comments:\r
  83 >> \r
  84 >> In patch 2 perhaps notmuch-tag-completions could have a docstring.\r
  85 >\r
  86 > Added.  I noticed that I had failed to update the call from\r
  87 > `notmuch-select-tag-with-completion', so I fixed that, too.  I don't\r
  88 > understand why we take lists of search terms in random places and\r
  89 > never use more than one element, but I suppose this series doesn't\r
  90 > make that any worse.\r
  91 \r
  92 As far as I can see, at the end of the series, notmuch-tag-completions\r
  93 is only called with no argument: i.e., it's always just finding the list\r
  94 of all tags. This is because notmuch-select-tag-with-completion is only\r
  95 called once from "notmuch-search-filter-by-tag" with no search-terms\r
  96 argument. So it might be nice to just remove the search-terms\r
  97 completely. (The only downside is we might break user lisp.)\r
  98 \r
  99 Best wishes\r
 100 \r
 101 Mark\r
 102 \r
 103 \r
 104 >> In Patch 4 I think the docstring for notmuch-search-tag is outdated: it\r
 105 >>  is "Change tags for the currently selected thread or region." but \r
 106 >>  beg and end can now be specified by the caller.\r
 107 >\r
 108 > I've left the first sentence as it is, since it's good interactive\r
 109 > documentation and a typical way to describe functions even if they\r
 110 > take a region as arguments (see, for example, `kill-region').  But\r
 111 > I've elaborated the rest of the docstring to be clearer about this.\r
 112 >\r
 113 >> and one actual comment:\r
 114 >> \r
 115 >> in patch 3 (for show) delete-dups is called before the list is passed to\r
 116 >> notmuch-read-tag-changes whereas it is not for search or pick.\r
 117 >> Obviously this is not actually a problem but it might be worth being\r
 118 >> consistent.\r
 119 >\r
 120 > Ah, whoops.  I'd done this before I decided to handle duplicates in\r
 121 > `notmuch-read-tag-changes'.  Since it's redundant, I've removed it.\r
 122 >\r
 123 >> But that was all I found. All tests pass and everything I try behaves\r
 124 >> exactly as expected.\r
 125 >> \r
 126 >> Best wishes\r
 127 >> \r
 128 >> Mark\r
 129 >> \r
 130 >> \r
 131 >> On Tue, 22 Oct 2013, Austin Clements <amdragon@MIT.EDU> wrote:\r
 132 >> > This series improves tag change completion in various ways for\r
 133 >> > commands like +, -, and *.\r
 134 >> >\r
 135 >> > From a user perspective, this provides command-specific prompts like\r
 136 >> > "Tag message" and "Tag all" instead of the generic "Tag" prompt, and\r
 137 >> > bases tag removal completions on the tags that are in the buffer,\r
 138 >> > rather than the current tags in the database, providing a more\r
 139 >> > predicable experience.\r
 140 >> >\r
 141 >> > From an implementation perspective, this new tag removal completion\r
 142 >> > behavior improves efficiency and eliminates a road block to fixing the\r
 143 >> > tagging race bug (which otherwise results in massive queries just to\r
 144 >> > compute removal completions).  The new code is also more "Elispy" and\r
 145 >> > predictable because all tag change prompting now occurs at the\r
 146 >> > interactive entry points, rather than buried under several layers of\r
 147 >> > non-interactive calls.\r
 148 >> >\r
 149 >> > This is a spiritual successor to\r
 150 >> > id:1354263691-19715-1-git-send-email-markwalters1009@gmail.com, though\r
 151 >> > it takes a very different approach.  This is also a prerequisite to\r
 152 >> > the tag race fix in\r
 153 >> > id:1381185201-25197-1-git-send-email-amdragon@mit.edu and I plan to\r
 154 >> > send an updated version of that series when this one is accepted.\r
 155 >> >\r
 156 >> > Patches 1, 5, and 6 could be pushed on their own.  They fix bugs or\r
 157 >> > sort of bugs that get in the way of the rest of the series.\r