Re: [ANNOUNCE] mutt with notmuch support
[notmuch-archives.git] / 12 / 91c331c87be13d943ca827a8ef458457686a47
1 Return-Path: <prvs=jrosenthal=71348ccb9@jhu.edu>\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 378464196F3\r
6         for <notmuch@notmuchmail.org>; Wed, 14 Apr 2010 10:50:53 -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: -1.5\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-1.5 tagged_above=-999 required=5\r
12         tests=[BAYES_50=0.8, RCVD_IN_DNSWL_MED=-2.3] 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 CeGhl3wqJuOZ for <notmuch@notmuchmail.org>;\r
16         Wed, 14 Apr 2010 10:50:52 -0700 (PDT)\r
17 Received: from ipex2.johnshopkins.edu (ipex2.johnshopkins.edu [162.129.8.151])\r
18         by olra.theworths.org (Postfix) with ESMTP id 2BD6A431FC1\r
19         for <notmuch@notmuchmail.org>; Wed, 14 Apr 2010 10:50:52 -0700 (PDT)\r
20 X-IronPort-Anti-Spam-Filtered: true\r
21 X-IronPort-Anti-Spam-Result: AvsEACydxUuA3DZF/2dsb2JhbACbVXG0c4hdhQ0E\r
22 X-IronPort-AV: E=Sophos;i="4.52,205,1270440000"; d="scan'208";a="321351554"\r
23 Received: from watt.gilman.jhu.edu ([128.220.54.69])\r
24         by ipex2.johnshopkins.edu with ESMTP/TLS/ADH-AES256-SHA;\r
25         14 Apr 2010 13:50:51 -0400\r
26 Received: by watt.gilman.jhu.edu (Postfix, from userid 502)\r
27         id 265DB4973B0; Wed, 14 Apr 2010 13:50:50 -0400 (EDT)\r
28 From: Jesse Rosenthal <jrosenthal@jhu.edu>\r
29 To: Carl Worth <cworth@cworth.org>, notmuch@notmuchmail.org\r
30 Subject: Re: [PATCH] Fix bug, and clean up code duplication,\r
31         in adding or removing tag by region.\r
32 In-Reply-To: <87zl16ez21.fsf@yoom.home.cworth.org>\r
33 References: <m1636w7au5.fsf@watt.gilman.jhu.edu> <87sk90ragj.fsf@jhu.edu>\r
34         <87aatfq88h.fsf@yoom.home.cworth.org> <877hogaf7v.fsf@jhu.edu>\r
35         <878w8rkzis.fsf@yoom.home.cworth.org> <871vejxk94.fsf@jhu.edu>\r
36         <87zl16ez21.fsf@yoom.home.cworth.org>\r
37 Date: Wed, 14 Apr 2010 13:50:50 -0400\r
38 Message-ID: <m1bpdlord1.fsf@watt.gilman.jhu.edu>\r
39 MIME-Version: 1.0\r
40 Content-Type: text/plain; charset=us-ascii\r
41 X-BeenThere: notmuch@notmuchmail.org\r
42 X-Mailman-Version: 2.1.13\r
43 Precedence: list\r
44 List-Id: "Use and development of the notmuch mail system."\r
45         <notmuch.notmuchmail.org>\r
46 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
47         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
48 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
49 List-Post: <mailto:notmuch@notmuchmail.org>\r
50 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
51 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
52         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
53 X-List-Received-Date: Wed, 14 Apr 2010 17:50:53 -0000\r
54 \r
55 On Wed, 14 Apr 2010 10:14:46 -0700, Carl Worth <cworth@cworth.org> wrote:\r
56 > The only real problem I see with this approach is that it's fragile in\r
57 > depending on the buffer having exactly 2 lines of non-thread text at the\r
58 > end. I can easily see myself wanting to remove the "End of Search\r
59 > Results" line at the end of the buffer. And if I do that, this code will\r
60 > break, (tag manipulations will miss the last message).\r
61 \r
62 I was a bit worried about that myself. I hard-coded the 2 based on the\r
63 hard-coding in `notmuch-search-last-thread' (">"), which currently goes\r
64 to the bottom and then goes up two lines. But it seems like if there\r
65 were a more robust approach, it could be used in both.\r
66 \r
67 > A more robust fix would check for the ability to read a thread\r
68 > ID. So making a single function such as\r
69 > notmuch-search-find-last-line-with-thread-id or so would do the trick\r
70 > here.\r
71 \r
72 It occurs to me that the best way to do this would probably be to go to\r
73 point-max, and then (forward-line -1) until we hit a thread-id. That way\r
74 we wouldn't have to work all the way down long search indexes. I'll try\r
75 to code that up for the next release, and then have\r
76 notmuch-search-last-thread use it, as well as the region functions.\r
77 \r
78 Best,\r
79 Jesse\r