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 88F7742118E for ; Wed, 29 Jun 2011 13:21:15 -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 lz316UQXm+u7 for ; Wed, 29 Jun 2011 13:21:14 -0700 (PDT) Received: from mail-iw0-f181.google.com (mail-iw0-f181.google.com [209.85.214.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id C07CA421192 for ; Wed, 29 Jun 2011 13:21:14 -0700 (PDT) Received: by iwn37 with SMTP id 37so1502631iwn.26 for ; Wed, 29 Jun 2011 13:21:14 -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=d7HB8+PlcmfXTrgTWXMn6Fsoc9IAbmNcsOGjIlx64o4=; b=QnGDlb0hMTAf6VO7Bcrbka4j9DGjf38NPgGzynrAcjK0hKI9qhZ3fu3WC4QqFyAN5j u/QNtI0D4GmIj5zW0YLfjpNOBw9+5XNlhAdok+0FIjwAR/En5pnjip4JT/zUkmxbiHUn X4579YhngnL0ZfjAYZdi+1KsrSVW5xytXUsNc= Received: by 10.231.48.197 with SMTP id s5mr996902ibf.193.1309378874321; Wed, 29 Jun 2011 13:21:14 -0700 (PDT) Received: from localhost ([74.205.145.146]) by mx.google.com with ESMTPS id j1sm779439ibg.21.2011.06.29.13.21.12 (version=TLSv1/SSLv3 cipher=OTHER); Wed, 29 Jun 2011 13:21:12 -0700 (PDT) From: Mark Anderson To: Carl Worth , Sander Boer Subject: Re: notmuch Digest, Vol 20, Issue 57 In-Reply-To: <87tyb97bt1.fsf@yoom.home.cworth.org> References: <87wrg5905c.fsf@yoom.home.cworth.org> <87hb79intl.fsf@gmail.com> <87tyb97bt1.fsf@yoom.home.cworth.org> User-Agent: Notmuch/0.5-283-gb744eac (http://notmuchmail.org) Emacs/23.2.1 (i686-pc-linux-gnu) Date: Wed, 29 Jun 2011 14:21:11 -0600 Message-ID: <877h84ie2w.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 20:21:15 -0000 On Tue, 28 Jun 2011 16:53:30 -0700, Carl Worth wrote: > On Tue, 28 Jun 2011 16:38:30 -0600, Mark Anderson wrote: > > I had briefly considered adding another output format "file", just to get a > > single file for each message in the db, but the file/files distinction > > feels a bit niggling. Perhaps it should be changed to "files" and > > "filelists" or something else more clear. > > Another option that would be general to several commands would be: > > notmuch search --output=files --exclude-duplicates > > Or alternately, --include-duplicates. That might be more useful for > "notmuch show" which is a case where users have previously asked for the > ability to ask for duplicate messages, (and where the duplicates are > squelched by default). > > Thoughts? 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. I understand that we could use --include-duplicates, but I don't think there are currently any output specifers that actually have a plurality for a single message. If we had something like --output=from, or some other message attribute, then I think we would achieve more useful orthogonality from adding an argument similar to --include-duplicates. As it stands, it looks better to me to have a different --output specifier to represent the uncommon case of multiple outputs per search match. -Mark