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 36D63429E25 for ; Fri, 24 Jun 2011 13:34:15 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.699 X-Spam-Level: X-Spam-Status: No, score=-0.699 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled 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 A0raX5-RHarv for ; Fri, 24 Jun 2011 13:34:13 -0700 (PDT) Received: from mail-wy0-f181.google.com (mail-wy0-f181.google.com [74.125.82.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 0BC11431FD0 for ; Fri, 24 Jun 2011 13:34:12 -0700 (PDT) Received: by wyh22 with SMTP id 22so271548wyh.26 for ; Fri, 24 Jun 2011 13:34:11 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=domainkey-signature:sender:date:from:to:cc:subject:message-id :references:mime-version:content-type:content-disposition :in-reply-to:user-agent; bh=6Ks9O1sa0WZFVTmbKkmGfJIqJi84MkEjI9xP8M1Vvrk=; b=IAFQH5ac3K6GSb0mypBIhe+YpCsSHVKdyK/0oVw/BFZre5UEWMIP0EwNzzD8WFTsOh ky3YjvWR4Pf7qK9Ofg7BA1VgPa0n+SI49R/ebl8fVrOYpgOKgXyTQOtr0LAGAVuMKBmv V68n+criNMXw58XYRy0qDZMhpJfcy7dTuT7rk= DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma; h=sender:date:from:to:cc:subject:message-id:references:mime-version :content-type:content-disposition:in-reply-to:user-agent; b=iuQpfQWTIJXzPzoK2HhCvG0W8mnmmX+SeOcnkkEvExg7hpqQdtfUvx/SKoM2bf0qQT 2qPKEsdKqeeC/2GpSGWPH0bR3b6jNxDyyAAVIP8zl4b2CT/xt3txV8B71diDkI/BcIMh 6lI3qq315iOeuobXaiz4Y8G1Nyu8zxhacbnWM= Received: by 10.216.62.3 with SMTP id x3mr43152wec.77.1308947651571; Fri, 24 Jun 2011 13:34:11 -0700 (PDT) Received: from localdomain ([78.222.14.116]) by mx.google.com with ESMTPS id fe4sm1458510wbb.28.2011.06.24.13.34.10 (version=SSLv3 cipher=OTHER); Fri, 24 Jun 2011 13:34:10 -0700 (PDT) Sender: Louis Rilling Date: Fri, 24 Jun 2011 22:34:03 +0200 From: Louis Rilling To: Austin Clements Subject: Re: [RFC][PATCH] tags_to_maildir_flags: Add option to not move messages from "new/" to "cur/" Message-ID: <20110624203403.GA2523@localdomain> References: <1308843366-6159-1-git-send-email-l.rilling@av7.net> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.5.20 (2009-06-14) Cc: notmuch@notmuchmail.org 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: Fri, 24 Jun 2011 20:34:15 -0000 On 24/06/11 11:19 -0400, Austin Clements wrote: > Welcome to notmuch! Thanks! > > From your description, I assume you're using both notmuch and another > MUA simultaneously. I'm betting that MUA is mutt (though please > correct me if I'm wrong). Correct :) > > Unfortunately, mutt's interpretation of maildir doesn't agree with the > rest of the world. I don't know of any other MUA that exposes the > distinction between mail in the "new" directory and mail in the "old" > directory (at least Dovecot, Evolution, Gnus, Kmail, and of course > notmuch don't). In other MUA's, any mail in the "new" directory is > immediately moved to "cur" and "new" mail is simply anything without > the seen flag. mutt, on the other hand, only considers mail in the > "new" directory to be "new". > > While the maildir specification is a little vague, it strongly implies > two things that mutt's approach violates: mail should never move from > "cur" to "new", and only mail in "cur" can have flags [1]. While it > never states it outright, the philosophy is that "new" is simply a > staging ground for incoming mail, not a user-visible state (and > certainly not user-manipulable). Thanks for the detailed explanation. > > Because of this, I don't think notmuch is the right place to change > this (certainly not in a way that would also violate the spec). Could > you elaborate a bit on your workflow? (In particular, are you using > mutt's distinction between new and old?) Maybe we can find an > alternate solution. Yes my quick "mood-dependent" filtering just acts on new (as shown by mutt) mails, while old mails are kept until either 1) they can be read (yes, this happens!), or 2) they can be archived (because they might be interesting in some future), or 3) they can be deleted (eg. became too old to be worth reading them). However, I don't think that I need the violating behavior of mutt: new mails are just new, not replied to/read, or anything else. The only rare cases in which I may set back the new flag are when I mistakenly start reading an email (wrong keystroke most of the time). Even in that case, I don't care if the mail becomes old (ie moves to cur/). Maybe the alternate solution could consist in simply not renaming emails having no flags to be changed (Currently notmuch_message_tags_to_maildir_flags() unconditionally moves messages from new/ to cur/). This would even lead to a shorter patch :) Do you think that this would be acceptable? Thanks, Louis > > [1] There's a bug open about the second problem (thanks to ccxCZ for > finding this): > http://dev.mutt.org/trac/ticket/2476 > Of course, fixing that implies addressing the first problem, too. > > On Thu, Jun 23, 2011 at 11:36 AM, Louis Rilling wrote: > > notmuch_message_tags_to_maildir_flags() moves messages from maildir directory > > "new/" to maildir directory "cur/", which makes messages lose their "new" status > > in the MUA. However some users want to keep this "new" status after, for > > instance, an auto-tagging of new messages. > > > > This patch introduces notmuch_message_tags_to_maildir_flags_preserve(), which > > does the same job as notmuch_message_tags_to_maildir_flags() except moving > > from "maildir "new/" to maildir "cur/". A new option "preserve_new" is > > introduced in "[maildir]" section of .notmuch-config, so that users can > > configure whether commands "notmuch tag" and "notmuch restore" preserve the > > "new" status or not. > > > > Signed-off-by: Louis Rilling > > --- > > Hi, > > > > I'm in the process of using notmuch, but the issue "addressed" by this patch > > would make me change my habits a bit too fast. I use the "new" status for > > quickly checking (often without reading) which emails I just received, > > implementing some kind of context/mood/daytime-dependent quick filtering. I'd > > also like to run a pre-tagging script automatically when synchronizing > > periodically (and automatically too) my mailboxes. But the current behavior of > > "notmuch tag" makes me lose my quick filtering ability. > > > > This patch is mostly written for discussion. It is certainly not polished (API, > > ABI, bindings) and not tested at all. In particular, I know that there are some > > plans to customize flags synchronization, but I don't know how the library API > > could/should be impacted. > > > > Thanks for your comments! > > > > Louis