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