[WIP PATCH] emacs: show: reply to calendar parts
[notmuch-archives.git] / b6 / 2d2f109fc7b60604e150b9853e12ec99287557
1 Return-Path: <dkg@fifthhorseman.net>\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 arlo.cworth.org (Postfix) with ESMTP id 60FDE6DE00F5\r
6  for <notmuch@notmuchmail.org>; Thu, 14 Jul 2016 09:22:14 -0700 (PDT)\r
7 X-Virus-Scanned: Debian amavisd-new at cworth.org\r
8 X-Spam-Flag: NO\r
9 X-Spam-Score: 0\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=0 tagged_above=-999 required=5 tests=[none]\r
12  autolearn=disabled\r
13 Received: from arlo.cworth.org ([127.0.0.1])\r
14  by localhost (arlo.cworth.org [127.0.0.1]) (amavisd-new, port 10024)\r
15  with ESMTP id yRgyJLHV0jL3 for <notmuch@notmuchmail.org>;\r
16  Thu, 14 Jul 2016 09:22:05 -0700 (PDT)\r
17 Received: from che.mayfirst.org (che.mayfirst.org [162.247.75.118])\r
18  by arlo.cworth.org (Postfix) with ESMTP id CC8A36DE00C9\r
19  for <notmuch@notmuchmail.org>; Thu, 14 Jul 2016 09:22:05 -0700 (PDT)\r
20 Received: from fifthhorseman.net (pD95765AE.dip0.t-ipconnect.de\r
21  [217.87.101.174])\r
22  by che.mayfirst.org (Postfix) with ESMTPSA id 8A17DF98B;\r
23  Thu, 14 Jul 2016 12:22:03 -0400 (EDT)\r
24 Received: by fifthhorseman.net (Postfix, from userid 1000)\r
25  id 3D9CC20111; Thu, 14 Jul 2016 18:22:02 +0200 (CEST)\r
26 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
27 To: David Bremner <david@tethera.net>, Notmuch Mail <notmuch@notmuchmail.org>\r
28 Subject: Re: [PATCH v4 09/16] index encrypted parts when asked.\r
29 In-Reply-To: <87lh14e2x8.fsf@tesseract.cs.unb.ca>\r
30 References: <1467970047-8013-1-git-send-email-dkg@fifthhorseman.net>\r
31  <1467970047-8013-10-git-send-email-dkg@fifthhorseman.net>\r
32  <87lh14e2x8.fsf@tesseract.cs.unb.ca>\r
33 User-Agent: Notmuch/0.22+77~gaba8744 (https://notmuchmail.org) Emacs/24.5.1\r
34  (x86_64-pc-linux-gnu)\r
35 Date: Thu, 14 Jul 2016 18:22:01 +0200\r
36 Message-ID: <8737ncmbpy.fsf@alice.fifthhorseman.net>\r
37 MIME-Version: 1.0\r
38 Content-Type: text/plain\r
39 X-BeenThere: notmuch@notmuchmail.org\r
40 X-Mailman-Version: 2.1.20\r
41 Precedence: list\r
42 List-Id: "Use and development of the notmuch mail system."\r
43  <notmuch.notmuchmail.org>\r
44 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
45  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
46 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
47 List-Post: <mailto:notmuch@notmuchmail.org>\r
48 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
49 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
50  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
51 X-List-Received-Date: Thu, 14 Jul 2016 16:22:14 -0000\r
52 \r
53 On Thu 2016-07-14 15:59:15 +0200, David Bremner wrote:\r
54 > Daniel Kahn Gillmor <dkg@fifthhorseman.net> writes:\r
55 >\r
56 >> +    status = _notmuch_crypto_get_gmime_ctx_for_protocol (&(indexopts->crypto),\r
57 >> +                                                     protocol, &crypto_ctx);\r
58 >> +    if (status) {\r
59 >> +    _notmuch_database_log (notmuch, "Warning: setup failed for decrypting "\r
60 >> +                           "during indexing. (%d)\n", status);\r
61 >> +    status = notmuch_message_add_property (message, "index-decryption", "failure");\r
62 >> +    if (status)\r
63 >> +        _notmuch_database_log (notmuch, "failed to add index-decryption "\r
64 >> +                               "property (%d)\n", status);\r
65 >> +    return;\r
66 >> +    }\r
67 >\r
68 > Currently the only correct usage of _notmuch_database_log is the\r
69 > following pattern\r
70 >\r
71 >           _notmuch_database_log (notmuch, "Cannot write to a read-only database.\n");\r
72 >           return NOTMUCH_STATUS_READ_ONLY_DATABASE;\r
73 >\r
74 > In particular, the log buffer is only one line, and the caller needs to\r
75 > know to retrieve it.\r
76 >\r
77 > I agree it's not ideal, but I doubt you want to delay your stuff in\r
78 > order to extend/fix the internal logging API.\r
79 \r
80 I understand that the internal log is currently only a single line, but\r
81 following the usage pattern you describe isn't useful for this case.\r
82 \r
83 What is your suggested fix?  a given message could have multiple parts,\r
84 some of which are decryptable and others of which are not.\r
85 \r
86 It makes no sense to stop indexing a message just because one of the\r
87 parts failed to decrypt, so i'm not going to immediately return.\r
88 \r
89 I'm willing to accept that only the last log message will make it out to\r
90 the caller, and i could track whether anything has been written to the\r
91 log and change the return value in that case.  would that be acceptable?\r
92 \r
93     --dkg\r