Return-Path: X-Original-To: notmuch@notmuchmail.org Delivered-To: notmuch@notmuchmail.org Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 0D591431FBC for ; Mon, 1 Feb 2010 06:55:26 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: 0.001 X-Spam-Level: X-Spam-Status: No, score=0.001 tagged_above=-999 required=5 tests=[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 0-eZkl--620c for ; Mon, 1 Feb 2010 06:55:25 -0800 (PST) Received: from homiemail-a17.g.dreamhost.com (mailbigip.dreamhost.com [208.97.132.5]) by olra.theworths.org (Postfix) with ESMTP id 493F8431FAE for ; Mon, 1 Feb 2010 06:55:25 -0800 (PST) Received: from sspaeth.de (mtec-hg-docking-1-dhcp-204.ethz.ch [129.132.133.204]) by homiemail-a17.g.dreamhost.com (Postfix) with ESMTPA id 7CD0C7A8064 for ; Mon, 1 Feb 2010 06:55:23 -0800 (PST) Received: by sspaeth.de (sSMTP sendmail emulation); Mon, 01 Feb 2010 15:55:21 +0100 From: "Sebastian Spaeth" To: notmuch@notmuchmail.org In-Reply-To: <87wrz3zl94.fsf@gmail.com> Date: Mon, 01 Feb 2010 15:55:21 +0100 Message-ID: <87y6jd3t0m.fsf@SSpaeth.de> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Subject: Re: [notmuch] Some thoughts about notmuch sync with other agents 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: Mon, 01 Feb 2010 14:55:26 -0000 --=-=-= REPOSTING, as the previous reply went to Gmane > One may > or may not like IMAP for good reasons, the fact is that it is here and > has allowed users to read mails from various places and terminals, > keeping important information synced. So I think that notmuch will have > to live with that, and provide what is required to integrate smoothly > into this environment. agreed > First of all, processing mail with MUA involves some simple logic that > is shared by most MUA. This is about receiving *new* mails, *reading* > mail, *replying* to mail and so on... IMHO, this really belongs to the > mail processing logic and not to the user logic. Hence my first > request : > 1: Don't use user tags space to store MUA flags. I don't really see what you gain by this proposal. I don't necessarily think it's bad either, but there is no advantage IMHO. What you propose is basically that those tags are not directly seen by the user and not modifiable by the user. What's the advantage over having a small set of "reserved tag keywords"? Your notmuch-capable editor could still chose to not display "unread" and "deleted" tags but simply hide deleted mails and show unread mails in bold or so. I simply don't think it's important how tags are stored and the current scheme is dead simple which makes it pretty nice. > That means no more "seen", "unread", "replied" as tags. These are > MUA processing *flags*, that must belong to an established set. > Tags, on the other hand, are user-land information. So no more > [seen, replied, grandma, important] tag sets :) See above, the mail editor might chose to hide thos MUA processing flags, but I don't think it is important whether they are hidden by the user or now. Other than that, I agree that "notmuch new" should set a "new" and/or "modified"tag if it detects a new mail (or a modified one), rather than the current set of fixed tags that aren't too helpful for 3rd party scripts. Sebastian --=-=-= Date: Mon, 01 Feb 2010 15:54:57 +0100 Message-ID: <871vh557lq.fsf@SSpaeth.de> --=-=-=--