Re: [feature request] emacs: use `notmuch insert` for FCC
[notmuch-archives.git] / 76 / 6054d09dfb326a85e7b0ba485a4084daf31b54
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 4469E40D16C\r
6         for <notmuch@notmuchmail.org>; Sat, 30 Oct 2010 06:01:49 -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.9\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-1.9 tagged_above=-999 required=5\r
12         tests=[BAYES_00=-1.9] autolearn=unavailable\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 q-Lt2Tti4cwq for <notmuch@notmuchmail.org>;\r
16         Sat, 30 Oct 2010 06:01:38 -0700 (PDT)\r
17 Received: from max.feld.cvut.cz (max.feld.cvut.cz [147.32.192.36])\r
18         by olra.theworths.org (Postfix) with ESMTP id 5941A40D167\r
19         for <notmuch@notmuchmail.org>; Sat, 30 Oct 2010 06:01:26 -0700 (PDT)\r
20 Received: from localhost (unknown [192.168.200.4])\r
21         by max.feld.cvut.cz (Postfix) with ESMTP id 5BC7019F32FD;\r
22         Sat, 30 Oct 2010 15:01:25 +0200 (CEST)\r
23 X-Virus-Scanned: IMAP AMAVIS\r
24 Received: from max.feld.cvut.cz ([192.168.200.1])\r
25         by localhost (styx.feld.cvut.cz [192.168.200.4]) (amavisd-new,\r
26         port 10044)\r
27         with ESMTP id ntlXbL76wkij; Sat, 30 Oct 2010 15:01:23 +0200 (CEST)\r
28 Received: from imap.feld.cvut.cz (imap.feld.cvut.cz [147.32.192.34])\r
29         by max.feld.cvut.cz (Postfix) with ESMTP id D4C3919F32FF;\r
30         Sat, 30 Oct 2010 15:01:23 +0200 (CEST)\r
31 Received: from wsheee.2x.cz (charon.finaltek.com [217.11.241.201])\r
32         (Authenticated sender: sojkam1)\r
33         by imap.feld.cvut.cz (Postfix) with ESMTPSA id C0FE9FA005;\r
34         Sat, 30 Oct 2010 15:01:23 +0200 (CEST)\r
35 Received: from wsh by wsheee.2x.cz with local (Exim 4.72)\r
36         (envelope-from <sojkam1@fel.cvut.cz>)\r
37         id 1PCAJi-0004V4-6k; Sat, 30 Oct 2010 14:13:50 +0200\r
38 From: Michal Sojka <sojkam1@fel.cvut.cz>\r
39 To: Carl Worth <cworth@cworth.org>, Dirk Hohndel <hohndel@infradead.org>,\r
40         Matt Fleming <matt@console-pimps.org>, notmuch@notmuchmail.org\r
41 Subject: Re: [PATCH 0/4] Maildir synchronization\r
42 In-Reply-To: <87sjzopmga.fsf@yoom.home.cworth.org>\r
43 References: <1273580061-22580-1-git-send-email-sojkam1@fel.cvut.cz>\r
44         <87d3w082dh.fsf@linux-g6p1.site> <m3zkz3d210.fsf@x201s.gr8dns.org>\r
45         <87typbzdnt.fsf@steelpick.2x.cz>\r
46         <87sjzopmga.fsf@yoom.home.cworth.org>\r
47 User-Agent: Notmuch/0.3.1-113-g782e2e3 (http://notmuchmail.org) Emacs/23.2.1\r
48         (i486-pc-linux-gnu)\r
49 Date: Sat, 30 Oct 2010 14:13:50 +0200\r
50 Message-ID: <87tyk3vpxd.fsf@wsheee.2x.cz>\r
51 MIME-Version: 1.0\r
52 Content-Type: text/plain; charset=us-ascii\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: Sat, 30 Oct 2010 13:01:49 -0000\r
66 \r
67 On Sat, 30 Oct 2010, Carl Worth wrote:\r
68 > On Thu, 10 Jun 2010 06:59:02 +0200, Michal Sojka <sojkam1@fel.cvut.cz> wrote:\r
69 > > This is a known limitation.\r
70 > > From id:1273580061-22580-3-git-send-email-sojkam1@fel.cvut.cz:\r
71 > > \r
72 > >    The reason is that when you view the message its unread tag is\r
73 > >    removed which leads to rename of the file, but Emacs still uses the\r
74 > >    original name to access the attachment.\r
75 > > \r
76 > >    Workaround: close the message and open it again.\r
77\r
78 > These patches do indeed look very interesting. But the above limitation\r
79 > is really too severe. It just breaks things to much. Let's get that\r
80 > fixed first.\r
81\r
82 > > IMHO, the final solution to this issue would be the "notmuch cat"\r
83 > > command. With this command, emacs would not access the messages by file\r
84 > > name, but by message id.\r
85\r
86 > Sounds like a great idea. Instead of "notmuch cat", how about we name\r
87 > this "notmuch show --format=raw"? That should be even easier to\r
88 > implement, too.\r
89 \r
90 See id:1287739684-26188-1-git-send-email-sojkam1@fel.cvut.cz for my last\r
91 attempt to implement this. I didn't implement it as --format=raw because\r
92 it seems that notmuch show always constructs threads even if they are\r
93 not used. I didn't check the code carefully so I may be wrong. Let me\r
94 know if you really prefer raw format over cat.\r
95 \r
96 > Finally, as for configuration, I don't like the numeric codes for this\r
97 > feature. Do we really need that much granularity in the functionality\r
98 > here? Other mail clients certainly don't. From what I can see, most mail\r
99 > clients just twiddle these flags unconditionally.\r
100\r
101 > I can imagine some people might want to be able to turn the feature off\r
102 > entirely, so maybe we'll need that.>\r
103 \r
104 I agree that having only on/off settings should be sufficient for most\r
105 users. I'll send updated patches in a while.\r
106  \r
107 > Or perhaps more importantly than configuration, we need the ability to\r
108 > easily migrate people to a synchronized state. For example, in my\r
109 > current mail store, most filenames have never been changed, so I've got\r
110 > a lot of files with flags that don't match my tags. What do you think\r
111 > would be the best way to resolve a situation like that?\r
112 \r
113 One thing is that if you simply enable maildir synchronization and run\r
114 notmuch new, it should not touch your tags as the tags are modified only\r
115 when a new or renamed message is found. So if one doesn't modify the\r
116 flags by other programs it is safe to enable maildir synchronization.\r
117 \r
118 Then, if other programs that may modify the flags are used, the mail\r
119 store flags should be made synchronized. One way of doing this manually\r
120 is to execute the following sequence of commands after enabling maildir\r
121 synchronization.\r
122 \r
123 notmuch dump > x    # stores the tags\r
124 notmuch new         # makes sure that the file names in the database are up to date\r
125 notmuch restore < x # sets maildir flags to match the tags\r
126 \r
127 If you want this to happen automatically, it might be possible to\r
128 modify notmuch new to use something like\r
129 notmuch->xapian_db->get_metadata("maildir_in_sync") and if this metadata\r
130 is not found and the maildir synchronization is enabled then it would\r
131 synchronize the flags and set the database metadata.\r
132 \r
133 -Michal\r