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 1098242119A for ; Wed, 29 Jun 2011 15:19:48 -0700 (PDT) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-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 MQbouCCmPe5z for ; Wed, 29 Jun 2011 15:19:47 -0700 (PDT) Received: from mail-iy0-f181.google.com (mail-iy0-f181.google.com [209.85.210.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 8586D42118E for ; Wed, 29 Jun 2011 15:19:47 -0700 (PDT) Received: by iyf40 with SMTP id 40so1601641iyf.26 for ; Wed, 29 Jun 2011 15:19:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type; bh=qPo1wfQ0Talm7BRDzPCeKeu8TGIj6uVdAbiY/0SH+HQ=; b=cnx2B0jLOAJF2XyCHxEWgXhaLDQmG+ljYIsK8Z/E9gTRAnB/sgDi6GJLfsBQl/DOhi iWeXkmUKJkevC37+7D87TzHFA3tCEK3s6Q/sU808+AJUBy5rgD3/pupwN2PFMDpvUm6y kGu41MHTZQB7zrKixVOhOwCj+tUFawl43JedU= Received: by 10.43.47.134 with SMTP id us6mr1469712icb.10.1309385986919; Wed, 29 Jun 2011 15:19:46 -0700 (PDT) Received: from localhost ([74.205.145.146]) by mx.google.com with ESMTPS id in11sm828076ibb.22.2011.06.29.15.19.45 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 15:19:46 -0700 (PDT) From: Mark Anderson To: Jameson Graef Rollins , Carl Worth , Sander Boer Subject: Re: notmuch Digest, Vol 20, Issue 57 In-Reply-To: <87aad0xsrz.fsf@servo.factory.finestructure.net> References: <87wrg5905c.fsf@yoom.home.cworth.org> <87hb79intl.fsf@gmail.com> <87tyb97bt1.fsf@yoom.home.cworth.org> <877h84ie2w.fsf@gmail.com> <87aad0xsrz.fsf@servo.factory.finestructure.net> User-Agent: Notmuch/0.5-283-gb744eac (http://notmuchmail.org) Emacs/23.2.1 (i686-pc-linux-gnu) Date: Wed, 29 Jun 2011 16:19:44 -0600 Message-ID: <874o38i8lb.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii 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: Wed, 29 Jun 2011 22:19:48 -0000 On Wed, 29 Jun 2011 13:54:40 -0700, Jameson Graef Rollins wrote: > On Wed, 29 Jun 2011 14:21:11 -0600, Mark Anderson wrote: > > I personally prefer --output=files remain as it was, with one file per > > mail (even though I submitted the patch to change it). I suggest that > > we could add another format to supply all files (perhaps > > --output=allfiles, or --output=dupfiles). I don't like my original > > suggestion of "filelists" because it implies a list of lists to me. A > > list of lists would correlate better to the number of messages which > > match the search terms, but doesn't correlate well to xargs input. > > What's wrong with just outputting all the files matching the search, > including duplicates? I can't think of any reason where one would want > to not include all files matching the search. I would be curious to > hear a use case there. For someone who is using gmail + offlineimap, labels in gmail become folders in maildir. The maildir structure can have a large number of copies of each email corresponding to the labels/tags which have been applied. To add a label/tag that is visible to the gmail interface, one should copy a file representing the message to the folder representing the gmail label, which will then sync to gmail. Copying more than one file for each message being labeled is more wasteful of time and storage. With all files returned, a simple xargs script to add a label by copying files will end up with many copies of the same file in the new directory. The consuming script could hunt for message-id's in files and uniquify, but since notmuch was doing that implicitly before, and it's fairly natural, it seems not a big deal to add. > Since I'm on this kick anyway, I'm going to keep pushing against further > customizations where there really isn't a need. With a common use case for the biggest email userbase which makes labels/tags natural, I think it is worth considering seriously. There are certainly other namesets which could be used to reprecent the two categories. I'm happy to use names that makes the 'allfiles' output the common case and the "one file/message" the longer string, but I think we should provide the "one file/message" output category. The 'allfiles' case is great for deleting all copies of an email, so I definitely want it to continue being available. -Mark