Re: [PATCH] emacs: wash: make word-wrap bound message width
[notmuch-archives.git] / f6 / 1c53c4dc9596949f7d5eef81aa2c973551b4ac
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 CA7D36DE0243\r
6  for <notmuch@notmuchmail.org>; Fri,  1 Apr 2016 18:50:21 -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 5IbO_3VX6i4Y for <notmuch@notmuchmail.org>;\r
16  Fri,  1 Apr 2016 18:50:13 -0700 (PDT)\r
17 Received: from che.mayfirst.org (che.mayfirst.org [209.234.253.108])\r
18  by arlo.cworth.org (Postfix) with ESMTP id 97AA26DE00DF\r
19  for <notmuch@notmuchmail.org>; Fri,  1 Apr 2016 18:50:13 -0700 (PDT)\r
20 Received: from fifthhorseman.net (unknown [190.172.4.74])\r
21  by che.mayfirst.org (Postfix) with ESMTPSA id 4E774F99D\r
22  for <notmuch@notmuchmail.org>; Fri,  1 Apr 2016 21:50:11 -0400 (EDT)\r
23 Received: by fifthhorseman.net (Postfix, from userid 1000)\r
24  id BCA862059B; Fri,  1 Apr 2016 19:27:07 -0300 (BRT)\r
25 From: Daniel Kahn Gillmor <dkg@fifthhorseman.net>\r
26 To: Notmuch Mail <notmuch@notmuchmail.org>\r
27 Subject: Re: [PATCH] test thread breakage when messages are removed and\r
28  re-added\r
29 In-Reply-To: <1459445693-3900-1-git-send-email-dkg@fifthhorseman.net>\r
30 References: <1459445693-3900-1-git-send-email-dkg@fifthhorseman.net>\r
31 User-Agent: Notmuch/0.21+74~gb409435 (http://notmuchmail.org) Emacs/24.5.1\r
32  (x86_64-pc-linux-gnu)\r
33 Date: Fri, 01 Apr 2016 19:27:03 -0300\r
34 Message-ID: <8737r5dky0.fsf@alice.fifthhorseman.net>\r
35 MIME-Version: 1.0\r
36 Content-Type: multipart/signed; boundary="=-=-=";\r
37  micalg=pgp-sha512; protocol="application/pgp-signature"\r
38 X-BeenThere: notmuch@notmuchmail.org\r
39 X-Mailman-Version: 2.1.20\r
40 Precedence: list\r
41 List-Id: "Use and development of the notmuch mail system."\r
42  <notmuch.notmuchmail.org>\r
43 List-Unsubscribe: <https://notmuchmail.org/mailman/options/notmuch>,\r
44  <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
45 List-Archive: <http://notmuchmail.org/pipermail/notmuch/>\r
46 List-Post: <mailto:notmuch@notmuchmail.org>\r
47 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
48 List-Subscribe: <https://notmuchmail.org/mailman/listinfo/notmuch>,\r
49  <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
50 X-List-Received-Date: Sat, 02 Apr 2016 01:50:21 -0000\r
51 \r
52 --=-=-=\r
53 Content-Type: text/plain\r
54 \r
55 On Thu 2016-03-31 14:34:53 -0300, Daniel Kahn Gillmor <dkg@fifthhorseman.net> wrote:\r
56 > ghost-on-removal\r
57 > ----------------\r
58 >\r
59 > We could unilaterally add a ghost upon message removal.  This has a\r
60 > few disadvantages: the message index would leak information about what\r
61 > messages the user has ever been exposed to, and we also create a\r
62 > perpetually-growing dataset -- the ghosts can never be removed.\r
63 >\r
64 > ghost-on-removal-when-shared-thread-exists\r
65 > ------------------------------------------\r
66 >\r
67 > We could add a ghost upon message removal iff there are other\r
68 > non-ghost messages with the same thread ID.\r
69 >\r
70 > We'd also need to remove all ghost messages that share a thread when\r
71 > the last non-ghost message in that thread is removed.\r
72 >\r
73 > This still has a bit of information leakage, though: the message index\r
74 > would reveal that i've seen a newer message in a thread, even if i had\r
75 > deleted it from my message store\r
76 \r
77 One more proposal along these lines:\r
78 \r
79 track-non-ghost-count-per-thread\r
80 --------------------------------\r
81 \r
82 If each thread had a count of all the non-ghost messages associated with\r
83 it, and that count was properly maintained by the database, then upon\r
84 message deletion you would decrement the count.  when that count reached\r
85 zero, you could destroy the thread.\r
86 \r
87 This has the same metadata leakage as\r
88 ghost-on-removal-when-shared-thread-exists, but i think it might be more\r
89 efficient, if we can cope with the denormalized database.\r
90 \r
91 This does have the downside of needing a database transition, though:\r
92 we'd have to add this count to all threads in a database upgrade.\r
93 \r
94 \r
95 \r
96 What do people think of the different options?  what do you prefer?  is\r
97 there some better approach that i've missed?\r
98 \r
99      --dkg\r
100 \r
101 --=-=-=\r
102 Content-Type: application/pgp-signature; name="signature.asc"\r
103 \r
104 -----BEGIN PGP SIGNATURE-----\r
105 Version: GnuPG v2\r
106 \r
107 iQJ8BAEBCgBmBQJW/vW3XxSAAAAAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w\r
108 ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXRFREIyRTc0RjU2RkNGMkI2NzI5N0I3MzUy\r
109 NEVDRkY1QUZGNjgzNzBBAAoJECTs/1r/aDcKBFwP/3fiBCcA2W5KWe4R02JtO7qg\r
110 IuekGdsb95+HfauCrfdY5QQgSRmd6uIMniJkyZ9Zj4ccKEjPLDJ3nqn2M2xBHOzM\r
111 4j0b4CHmnhDZkNZAKgQCBjMMJVJ1qm4tTV380p1GOyChvQdxEHAelM3tT18rK/22\r
112 ynmBJ8bCzMJ4RjG1rfLWqc9DA78AZCVxPj2Ikc+jKBRFc6UvdtOq5/dCgkykOfTV\r
113 lXFvO1BWwkH/6E9xijg7bl6sMGUsJzdLq0Jc5pTRYCyAMMv5DQlj1JllvQAXKYCO\r
114 9v8ZVYCOPHrCF4BMrBldmOhK+aghbzYYzhLG77PKqwr0l2XsOtvwwD6A1L4Lo26O\r
115 vCY8sZUVWfzzL7hnvRaJhLxCiiTObjhN8GtpG/QpsQmOLw7uxbtIWx8OnDRmdQMJ\r
116 pWjjNyDFdvbw/3fogUoGpUHxB28cyDQ/rvASNDgE1pOQWkD1BM7fMShcc7F0g+tn\r
117 mpxpmmawFqrWA1pYiral/NL6MyPSIGWLZNfL0fYJbgX0aKB2Dpl4l+Pa4ZmbIxX1\r
118 bKkMahrQdoTPZOD4LmUov2aRSl4vMXjnJIlaHRqX70xk/E/dpkRA64XMNSAKtaCt\r
119 h5kYUNF4XnUUsEiknZYALCZfPmbMNfLw8GTJ+lGjEJRfGUBqBmh884SEcAklpOxi\r
120 JGbYC7K7Dr/IY75zMVMj\r
121 =TWtC\r
122 -----END PGP SIGNATURE-----\r
123 --=-=-=--\r