Re: [RFC PATCH v2 0/3] notmuch-pick: an emacs threaded message view with split-pane
[notmuch-archives.git] / 84 / 49c781eb48b1a9ab75b75a0d635a669006bd4f
1 Return-Path: <ma.skies@gmail.com>\r
2 X-Original-To: notmuch@notmuchmail.org\r
3 Delivered-To: notmuch@notmuchmail.org\r
4 Received: from localhost (localhost [127.0.0.1])\r
5         by olra.theworths.org (Postfix) with ESMTP id 1098242119A\r
6         for <notmuch@notmuchmail.org>; Wed, 29 Jun 2011 15:19:48 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.799\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5\r
12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1,\r
13         FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
14 Received: from olra.theworths.org ([127.0.0.1])\r
15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
16         with ESMTP id MQbouCCmPe5z for <notmuch@notmuchmail.org>;\r
17         Wed, 29 Jun 2011 15:19:47 -0700 (PDT)\r
18 Received: from mail-iy0-f181.google.com (mail-iy0-f181.google.com\r
19         [209.85.210.181]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
20         (No client certificate requested)\r
21         by olra.theworths.org (Postfix) with ESMTPS id 8586D42118E\r
22         for <notmuch@notmuchmail.org>; Wed, 29 Jun 2011 15:19:47 -0700 (PDT)\r
23 Received: by iyf40 with SMTP id 40so1601641iyf.26\r
24         for <notmuch@notmuchmail.org>; Wed, 29 Jun 2011 15:19:47 -0700 (PDT)\r
25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
26         h=from:to:cc:subject:in-reply-to:references:user-agent:date\r
27         :message-id:mime-version:content-type;\r
28         bh=qPo1wfQ0Talm7BRDzPCeKeu8TGIj6uVdAbiY/0SH+HQ=;\r
29         b=cnx2B0jLOAJF2XyCHxEWgXhaLDQmG+ljYIsK8Z/E9gTRAnB/sgDi6GJLfsBQl/DOhi\r
30         iWeXkmUKJkevC37+7D87TzHFA3tCEK3s6Q/sU808+AJUBy5rgD3/pupwN2PFMDpvUm6y\r
31         kGu41MHTZQB7zrKixVOhOwCj+tUFawl43JedU=\r
32 Received: by 10.43.47.134 with SMTP id us6mr1469712icb.10.1309385986919;\r
33         Wed, 29 Jun 2011 15:19:46 -0700 (PDT)\r
34 Received: from localhost ([74.205.145.146])\r
35         by mx.google.com with ESMTPS id in11sm828076ibb.22.2011.06.29.15.19.45\r
36         (version=TLSv1/SSLv3 cipher=OTHER);\r
37         Wed, 29 Jun 2011 15:19:46 -0700 (PDT)\r
38 From: Mark Anderson <ma.skies@gmail.com>\r
39 To: Jameson Graef Rollins <jrollins@finestructure.net>,\r
40         Carl Worth <cworth@cworth.org>, Sander Boer <sanboer@gmail.com>\r
41 Subject: Re: notmuch Digest, Vol 20, Issue 57\r
42 In-Reply-To: <87aad0xsrz.fsf@servo.factory.finestructure.net>\r
43 References: <mailman.5.1309146869.12973.notmuch@notmuchmail.org>\r
44         <cuozkl367o2.fsf@mauc.nl> <87wrg5905c.fsf@yoom.home.cworth.org>\r
45         <cuoliwlws13.fsf@mauc.nl> <87hb79intl.fsf@gmail.com>\r
46         <87tyb97bt1.fsf@yoom.home.cworth.org> <877h84ie2w.fsf@gmail.com>\r
47         <87aad0xsrz.fsf@servo.factory.finestructure.net>\r
48 User-Agent: Notmuch/0.5-283-gb744eac (http://notmuchmail.org) Emacs/23.2.1\r
49         (i686-pc-linux-gnu)\r
50 Date: Wed, 29 Jun 2011 16:19:44 -0600\r
51 Message-ID: <874o38i8lb.fsf@gmail.com>\r
52 MIME-Version: 1.0\r
53 Content-Type: text/plain; charset=us-ascii\r
54 Cc: notmuch@notmuchmail.org\r
55 X-BeenThere: notmuch@notmuchmail.org\r
56 X-Mailman-Version: 2.1.13\r
57 Precedence: list\r
58 List-Id: "Use and development of the notmuch mail system."\r
59         <notmuch.notmuchmail.org>\r
60 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
61         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
62 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
63 List-Post: <mailto:notmuch@notmuchmail.org>\r
64 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
65 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
66         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
67 X-List-Received-Date: Wed, 29 Jun 2011 22:19:48 -0000\r
68 \r
69 On Wed, 29 Jun 2011 13:54:40 -0700, Jameson Graef Rollins <jrollins@finestructure.net> wrote:\r
70 > On Wed, 29 Jun 2011 14:21:11 -0600, Mark Anderson <ma.skies@gmail.com> wrote:\r
71 > > I personally prefer --output=files remain as it was, with one file per\r
72 > > mail (even though I submitted the patch to change it).  I suggest that\r
73 > > we could add another format to supply all files (perhaps\r
74 > > --output=allfiles, or --output=dupfiles).  I don't like my original\r
75 > > suggestion of "filelists" because it implies a list of lists to me.  A\r
76 > > list of lists would correlate better to the number of messages which\r
77 > > match the search terms, but doesn't correlate well to xargs input.\r
78\r
79 > What's wrong with just outputting all the files matching the search,\r
80 > including duplicates?  I can't think of any reason where one would want\r
81 > to not include all files matching the search.  I would be curious to\r
82 > hear a use case there.\r
83 \r
84 For someone who is using gmail + offlineimap, labels in gmail become\r
85 folders in maildir.\r
86 \r
87 The maildir structure can have a large number of copies of each email\r
88 corresponding to the labels/tags which have been applied.\r
89 \r
90 To add a label/tag that is visible to the gmail interface, one should\r
91 copy a file representing the message to the folder representing the\r
92 gmail label, which will then sync to gmail.\r
93 \r
94 Copying more than one file for each message being labeled is more\r
95 wasteful of time and storage.\r
96 \r
97 With all files returned, a simple xargs script to add a label by copying\r
98 files will end up with many copies of the same file in the new\r
99 directory.\r
100 \r
101 The consuming script could hunt for message-id's in files and uniquify,\r
102 but since notmuch was doing that implicitly before, and it's fairly\r
103 natural, it seems not a big deal to add.\r
104 \r
105 > Since I'm on this kick anyway, I'm going to keep pushing against further\r
106 > customizations where there really isn't a need.\r
107 \r
108 With a common use case for the biggest email userbase which makes\r
109 labels/tags natural, I think it is worth considering seriously.\r
110 \r
111 There are certainly other namesets which could be used to reprecent the\r
112 two categories.  I'm happy to use names that makes the 'allfiles' output\r
113 the common case and the "one file/message" the longer string, but I\r
114 think we should provide the "one file/message" output category.\r
115 \r
116 The 'allfiles' case is great for deleting all copies of an email, so I\r
117 definitely want it to continue being available.\r
118 \r
119 -Mark\r
120 \r