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