af/2ec2d48ea9b8f1a3468d131ee1e37b5c9511c7

   1 Return-Path: <bgamari@gmail.com>\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 205EB431FBC\r
   6         for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 18:05:47 -0800 (PST)\r
   7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
   8 X-Spam-Flag: NO\r
   9 X-Spam-Score: -0.649\r
  10 X-Spam-Level: \r
  11 X-Spam-Status: No, score=-0.649 tagged_above=-999 required=5\r
  12         tests=[AWL=-0.650, BAYES_50=0.001] autolearn=ham\r
  13 Received: from olra.theworths.org ([127.0.0.1])\r
  14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
  15         with ESMTP id Hw5ODDkpy+3t for <notmuch@notmuchmail.org>;\r
  16         Sat, 16 Jan 2010 18:05:46 -0800 (PST)\r
  17 Received: from mail-qy0-f192.google.com (mail-qy0-f192.google.com\r
  18         [209.85.221.192])\r
  19         by olra.theworths.org (Postfix) with ESMTP id 19C2C431FAE\r
  20         for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 18:05:46 -0800 (PST)\r
  21 Received: by qyk30 with SMTP id 30so1262130qyk.32\r
  22         for <notmuch@notmuchmail.org>; Sat, 16 Jan 2010 18:05:45 -0800 (PST)\r
  23 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
  24         h=domainkey-signature:received:received:content-type:subject:from:to\r
  25         :in-reply-to:references:date:message-id:user-agent\r
  26         :content-transfer-encoding;\r
  27         bh=W4NpzLemIVEBBwUAJ8bT5dZ34SGKOR+KpQUcaN4yaS4=;\r
  28         b=jXXDM7d0JKWFwZ0eYKnQxXI6NQwf3x/gwLyO16FcrLqfGTGb7uqSH2VkYR4syokDh/\r
  29         xz/tQiuF2WZsEn9w4eQu1vuOCsN0neQnpL+VyPAydvFXglMdZFdOtbHpCCkHWbvMw6tK\r
  30         qkzDuiBbnK+MuLhfYE22OfS/ISJjsX/0FYxxk=\r
  31 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
  32         h=content-type:subject:from:to:in-reply-to:references:date:message-id\r
  33         :user-agent:content-transfer-encoding;\r
  34         b=i0Bn0mMX/p+P51TI7PhzG8oeuqlXxbaOtOkck8yZcHBlqS7ANKrzeQdplphEUF2Hg7\r
  35         v5zF/ilw/yLFZTxhZ1bIRJDQ7udS4UzU4uDPUFD94SjrqSUCO0MFHXnBFW/ZJHBhx0vR\r
  36         uKzaJQU2zZ0HuhPL3MeQnS4YRr9WdwvzTH6to=\r
  37 Received: by 10.224.101.141 with SMTP id c13mr3203551qao.21.1263693945395;\r
  38         Sat, 16 Jan 2010 18:05:45 -0800 (PST)\r
  39 Received: from localhost (pool-74-106-64-24.spfdma.east.verizon.net\r
  40         [74.106.64.24])\r
  41         by mx.google.com with ESMTPS id 6sm8316878qwd.6.2010.01.16.18.05.44\r
  42         (version=TLSv1/SSLv3 cipher=RC4-MD5);\r
  43         Sat, 16 Jan 2010 18:05:44 -0800 (PST)\r
  44 Content-Type: text/plain; charset=UTF-8\r
  45 From: Ben Gamari <bgamari@gmail.com>\r
  46 To: notmuch <notmuch@notmuchmail.org>\r
  47 In-reply-to: <20100116233840.GA31869@finestructure.net>\r
  48 References: <20100114084713.GA22273@harikalardiyari>\r
  49         <87eilse1hg.fsf@yoom.home.cworth.org>\r
  50         <20100115001600.GD25209@lapse.rw.madduck.net>\r
  51         <87vdf3cd1y.fsf@yoom.home.cworth.org>\r
  52         <20100115210934.GA12515@harikalardiyari>\r
  53         <87r5prc64e.fsf@yoom.home.cworth.org>\r
  54         <20100116201803.GA19570@finestructure.net>\r
  55         <87bpgtd71q.fsf@yoom.home.cworth.org>\r
  56         <20100116233840.GA31869@finestructure.net>\r
  57 Date: Sat, 16 Jan 2010 21:05:42 -0500\r
  58 Message-Id: <1263693410-sup-1275@ben-laptop>\r
  59 User-Agent: Sup/git\r
  60 Content-Transfer-Encoding: 8bit\r
  61 Subject: Re: [notmuch] inbox/unread tags for new messages [was: Re: Thoughts\r
  62         on notmuch and Lua]\r
  63 X-BeenThere: notmuch@notmuchmail.org\r
  64 X-Mailman-Version: 2.1.13\r
  65 Precedence: list\r
  66 List-Id: "Use and development of the notmuch mail system."\r
  67         <notmuch.notmuchmail.org>\r
  68 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
  69         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
  70 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
  71 List-Post: <mailto:notmuch@notmuchmail.org>\r
  72 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
  73 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
  74         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
  75 X-List-Received-Date: Sun, 17 Jan 2010 02:05:47 -0000\r
  76 \r
  77 Excerpts from Jameson Rollins's message of Sat Jan 16 18:38:40 -0500 2010:\r
  78 > On Sat, Jan 16, 2010 at 02:22:09PM -0800, Carl Worth wrote:\r
  79 > > So the idea with "new" is really to just make the lower-level pieces of\r
  80 > > notmuch, (the command-line interface and the library), to steal less of\r
  81 > > the tag namespace. Specifically, the proposal is to reserve a single tag\r
  82 > > ("new") rather than two tags ("inbox" and "unread"). Then, it's a matter\r
  83 > > of some higher-level layers (such as the emacs interface) to apply\r
  84 > > special meaning to things like "inbox" and "unread".\r
  85 > \r
  86 > I personally don't really think that this is a good idea.  If this is\r
  87 > all left up to mail reader, and the mail readers all do something\r
  88 > different, then it would be very difficult to switch readers, or to\r
  89 > use different readers for different circumstances.  I really think\r
  90 > that all of this stuff should be handled uniformly by the notmuch CLI\r
  91 > in a very structured way.  If we make sane decisions at that level,\r
  92 > then things are nicely consistent.\r
  93 > \r
  94 I strongly disagree. The fact that mail readers _might_ behave\r
  95 differently is not a good reason to enforce this on the notmuch layer.\r
  96 In fact, it might be that mail readers purposefully want to handle\r
  97 'inbox' and 'unread' differently. If that is what they want to do, then\r
  98 they should be able to. Even if tagging conventions do differ, it would\r
  99 be trivial to write a script to make the transition. This is because of\r
 100 notmuch's simplicity and flexibility and why it is important to keep it\r
 101 that way by avoiding adding unnecessary (even redundant) logic as you\r
 102 propose below.\r
 103 \r
 104 > What I would instead suggest is that there is a notmuch new hook,\r
 105 > handled at the notmuch program level, that would allow users to define\r
 106 > scripts or functions that would be applied to all new messages.  Then\r
 107 > users could do whatever they want to new messages.  As long as it's\r
 108 > done at the notmuch CLI level, instead of at the reader level, things\r
 109 > won't get fractured by divergent reader implementations.  This ideal\r
 110 > is also in line with the proposal I put forth in\r
 111 > id:20100116204955.GA858@finestructure.net.\r
 112 > \r
 113 I fail to see how this offers anything not provided by Carl's original\r
 114 proposal. As far as I can see, it adds more code to notmuch while\r
 115 providing no functionality not already attainable and while potentially\r
 116 placing limits on what is possible.\r
 117 \r
 118 In my opinion, notmuch should provide little more than a mail store.\r
 119 There are much better places to put this sort of policy than in notmuch.\r
 120 \r
 121 - Ben\r