Re: Integrating notmuch with gnus?
[notmuch-archives.git] / c0 / b0d3f94293116d5841c6e8d8f80164d4a451a1
1 Return-Path: <sojkam1@fel.cvut.cz>\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 27873431FDA\r
6         for <notmuch@notmuchmail.org>; Thu, 28 Jan 2010 07:24:16 -0800 (PST)\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: -0.866\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.866 tagged_above=-999 required=5\r
12         tests=[AWL=-0.867, BAYES_50=0.001] autolearn=ham\r
13 Received: from olra.theworths.org ([127.0.0.1])\r
14         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
15         with ESMTP id gU8bDC4hJ4qQ for <notmuch@notmuchmail.org>;\r
16         Thu, 28 Jan 2010 07:24:15 -0800 (PST)\r
17 Received: from mout.perfora.net (mout.perfora.net [74.208.4.195])\r
18         by olra.theworths.org (Postfix) with ESMTP id 5CCA7431FD5\r
19         for <notmuch@notmuchmail.org>; Thu, 28 Jan 2010 07:24:15 -0800 (PST)\r
20 Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])\r
21         by mx.perfora.net (node=mxus2) with ESMTP (Nemesis)\r
22         id 0MAwiS-1NSmT40Z2S-00A1iP for notmuch@notmuchmail.org;\r
23         Thu, 28 Jan 2010 10:24:14 -0500\r
24 Received: from localhost (unknown [192.168.200.4])\r
25         by max.feld.cvut.cz (Postfix) with ESMTP id 6428A19F33E1;\r
26         Thu, 28 Jan 2010 16:24:11 +0100 (CET)\r
27 X-Virus-Scanned: IMAP AMAVIS\r
28 Received: from max.feld.cvut.cz ([192.168.200.1])\r
29         by localhost (styx.feld.cvut.cz [192.168.200.4]) (amavisd-new,\r
30         port 10044)\r
31         with ESMTP id DJfKmfYQ6mLU; Thu, 28 Jan 2010 16:24:07 +0100 (CET)\r
32 Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])\r
33         by max.feld.cvut.cz (Postfix) with ESMTP id BF0A219F3340;\r
34         Thu, 28 Jan 2010 16:24:06 +0100 (CET)\r
35 Received: from steelpick.localnet (k335-30.felk.cvut.cz [147.32.86.30])\r
36         (Authenticated sender: sojkam1)\r
37         by imap.feld.cvut.cz (Postfix) with ESMTPSA id 5050EFA003;\r
38         Thu, 28 Jan 2010 16:24:05 +0100 (CET)\r
39 From: Michal Sojka <sojkam1@fel.cvut.cz>\r
40 To: notmuch@notmuchmail.org\r
41 Date: Thu, 28 Jan 2010 16:24:00 +0100\r
42 User-Agent: KMail/1.12.4 (Linux/2.6.31.11-amd64; KDE/4.3.4; x86_64; ; )\r
43 References: <200912141421.52561.lists@informa.tiker.net>\r
44         <87ljfjfsok.fsf@lillypad.riseup.net>\r
45 In-Reply-To: <87ljfjfsok.fsf@lillypad.riseup.net>\r
46 MIME-Version: 1.0\r
47 Content-Type: Text/Plain;\r
48   charset="iso-8859-15"\r
49 Content-Transfer-Encoding: 7bit\r
50 Message-Id: <201001281624.01577.sojkam1@fel.cvut.cz>\r
51 Cc: Andreas =?iso-8859-15?q?Kl=F6ckner?= <lists@informa.tiker.net>\r
52 Subject: Re: [notmuch] [patch] store folder information\r
53 X-BeenThere: notmuch@notmuchmail.org\r
54 X-Mailman-Version: 2.1.13\r
55 Precedence: list\r
56 List-Id: "Use and development of the notmuch mail system."\r
57         <notmuch.notmuchmail.org>\r
58 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
59         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
60 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
61 List-Post: <mailto:notmuch@notmuchmail.org>\r
62 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
63 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
64         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
65 X-List-Received-Date: Thu, 28 Jan 2010 15:24:16 -0000\r
66 \r
67 On Wednesday 27 of January 2010 16:55:55 micah anderson wrote:\r
68 > have not seen a reply from you yet. I'm particularly eager to see this\r
69 > get accepted upstream, and it sounds like the changes necessary to do so\r
70 > are relatively minor.\r
71 \r
72 Hi Micah and others,\r
73 \r
74 I wanted to test this patch, so I rebased it to the current HEAD. I had to do \r
75 it manually since notmuch evolved significantly since the original posting. \r
76 I'll post in followup mails.\r
77 \r
78 > I'm wondering what your plans are for addressing these issues? I've come\r
79 > to depend on this functionality, and would love to see it incorporated\r
80 > upstream!\r
81\r
82 > Specifically these were:\r
83\r
84 > 1. Unrelated whitespace:\r
85 \r
86 Fixed.\r
87  \r
88 > 2. An unrelated hunk creeping in:\r
89\r
90 > On Tue, 15 Dec 2009 13:22:19 -0800, Carl Worth <cworth@cworth.org> wrote:\r
91 > > On Mon, 14 Dec 2009 14:21:50 -0500, Andreas Kl=C3=B6ckner\r
92 > > <lists@informa.=\r
93\r
94 > tiker.net> wrote:\r
95 > > > @@ -116,6 +116,8 @@ skip_re_in_subject (const char *subject)\r
96 > > >       s++;\r
97 > > >   if (strncasecmp (s, "re:", 3) =3D=3D 0)\r
98 > > >       s +=3D 3;\r
99 > > > +        else if (strncasecmp (s, "aw:", 3) =3D=3D 0)\r
100 > > > +     s +=3D 3;\r
101 > > >   else\r
102 > > >       break;\r
103 > > >      }\r
104 \r
105 Fixed.\r
106 \r
107 > 3. Redundant trailing directory name traversal:\r
108 > > > +    gchar *full_folder_name =3D NULL;\r
109 > > > +    gchar *folder_base_name =3D NULL;\r
110 > > > +\r
111 > > > +    /* Find name of "folder" containing the email. */\r
112 > > > +    full_folder_name =3D g_strdup(path);\r
113 > > > +    while (1)\r
114 > > > +    {\r
115 > > > +        folder_base_name =3D g_path_get_basename(full_folder_name);\r
116 > >\r
117 > > The trailing directory name is available already during the\r
118 > > traversal. So you don't need to search it back out again. See the patch\r
119 > > in the following message:\r
120 > >\r
121 > >     id:87fx8bygi7.fsf@linux.vnet.ibm.com\r
122 > >\r
123 > > which simply passes the trailing directory name along, (but skipping a\r
124 > > name of "cur" or "new" while traversing).\r
125\r
126 > 4. supporting hierarchical folders (perhaps this is a later improvement\r
127\r
128 > that does not need to be added before the original patch is accepted?):\r
129 > > Beyond that, though, I imagine some people have hierarchical folders as\r
130 > > well, so it probably makes sense to store them as well.\r
131 > >\r
132 > > To do that, it's probably just a matter of calling gen_terms on the\r
133 > > complete filename. I haven't tested, but doing that should allow\r
134 > > Xapian's phrase searching to do the right thing for something like:\r
135 > >\r
136 > >     filename:portion/of/the/path/name\r
137 \r
138 I leave these two points for later since I do not have time for them now. If \r
139 somebody want to do it, let me know.\r
140 \r
141 Cheers\r
142 Michal\r