[PATCH 3/3] errors='ignore' when decode to unicode
[notmuch-archives.git] / 39 / 61ee94349481ba3cf4fec46183a1f3d45d339d
1 Return-Path: <amdragon@gmail.com>\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 A98FB429E28\r
6         for <notmuch@notmuchmail.org>; Wed, 25 May 2011 20:27:15 -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: -0.698\r
10 X-Spam-Level: \r
11 X-Spam-Status: No, score=-0.698 tagged_above=-999 required=5\r
12         tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, FREEMAIL_FROM=0.001,\r
13         HTML_MESSAGE=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled\r
14 Received: from olra.theworths.org ([127.0.0.1])\r
15         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
16         with ESMTP id tZfiWyiljMiY for <notmuch@notmuchmail.org>;\r
17         Wed, 25 May 2011 20:27:15 -0700 (PDT)\r
18 Received: from mail-qy0-f174.google.com (mail-qy0-f174.google.com\r
19         [209.85.216.174]) (using TLSv1 with cipher RC4-SHA (128/128 bits))\r
20         (No client certificate requested)\r
21         by olra.theworths.org (Postfix) with ESMTPS id CEE40431FB6\r
22         for <notmuch@notmuchmail.org>; Wed, 25 May 2011 20:27:14 -0700 (PDT)\r
23 Received: by qyk7 with SMTP id 7so2851586qyk.5\r
24         for <notmuch@notmuchmail.org>; Wed, 25 May 2011 20:27:14 -0700 (PDT)\r
25 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma;\r
26         h=domainkey-signature:mime-version:sender:date:x-google-sender-auth\r
27         :message-id:subject:from:to:cc:content-type;\r
28         bh=g483eQto+pCxIko3RKC4NK7aH/kiHptELsoCgy7HQMc=;\r
29         b=giuEY9ClHAW+TWa2fgN9uvF7yFBAqDqDutG1V0CVF+qM6aWMDBU9UIbKbAXr/osO4S\r
30         /QivhTVE+Swkj2ejpnMPd536UlPRj1lSTF/xR02fIEKciSs/zjQHonKOatY9x1UWynZ+\r
31         /QZDRf1tegIkZv5meVeOjo7d2htaea1uzG1eQ=\r
32 DomainKey-Signature: a=rsa-sha1; c=nofws; d=gmail.com; s=gamma;\r
33         h=mime-version:sender:date:x-google-sender-auth:message-id:subject\r
34         :from:to:cc:content-type;\r
35         b=ByprJATPvHPZ3+soIy7Mp6na0yC8LmOc2buRP7+geg8FevdE4tBJuMasTu5J3+K95K\r
36         4NzitHMeTlLvs+IeQ/2Ic6GmBwFjdZYS1TQAU9kIZ0uA5TTzLOiR9tA8oPhAIFFcl+O4\r
37         fHT36G4pXna5ayragebP8Eee4b9Ny+8a5lG08=\r
38 MIME-Version: 1.0\r
39 Received: by 10.229.78.218 with SMTP id m26mr206463qck.160.1306380434090; Wed,\r
40         25 May 2011 20:27:14 -0700 (PDT)\r
41 Sender: amdragon@gmail.com\r
42 Received: by 10.229.188.68 with HTTP; Wed, 25 May 2011 20:27:13 -0700 (PDT)\r
43 Received: by 10.229.188.68 with HTTP; Wed, 25 May 2011 20:27:13 -0700 (PDT)\r
44 Date: Wed, 25 May 2011 23:27:13 -0400\r
45 X-Google-Sender-Auth: jTQ2RQzIKMEHUMjeE0lK0yewspc\r
46 Message-ID: <BANLkTinYDQEX=C1s7dz4EmfbUO1G7VCg_w@mail.gmail.com>\r
47 Subject: Re: [PATCH] emacs: Make the queries used in the all-tags section\r
48 From: Austin Clements <amdragon@mit.edu>\r
49 To: Daniel Schoepe <daniel.schoepe@googlemail.com>\r
50 Content-Type: multipart/alternative; boundary=00235429d2f4b72c0704a42565f4\r
51 Cc: notmuch@notmuchmail.org\r
52 X-BeenThere: notmuch@notmuchmail.org\r
53 X-Mailman-Version: 2.1.13\r
54 Precedence: list\r
55 List-Id: "Use and development of the notmuch mail system."\r
56         <notmuch.notmuchmail.org>\r
57 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
58         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
59 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
60 List-Post: <mailto:notmuch@notmuchmail.org>\r
61 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
62 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
63         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
64 X-List-Received-Date: Thu, 26 May 2011 03:27:15 -0000\r
65 \r
66 --00235429d2f4b72c0704a42565f4\r
67 Content-Type: text/plain; charset=ISO-8859-1\r
68 \r
69 On May 25, 2011 7:21 PM, "Daniel Schoepe" <daniel.schoepe@googlemail.com>\r
70 wrote:\r
71 >\r
72 > On Wed, 25 May 2011 18:42:30 -0400, Austin Clements <amdragon@mit.edu>\r
73 wrote:\r
74 > > 'Doh.  That's what I get for not reading the surrounding code.  I\r
75 > > misunderstood what your patch was going for and assumed it was what\r
76 > > *I* wanted notmuch to do, which is to show me useful counts (e.g.,\r
77 > > unread count), but not to change the underlying query.  ]:--8)\r
78 >\r
79 > I thought about that too, but figured it should be rather rare that\r
80 > someone wants only a portion of some messages _counted_, but all\r
81 > displayed when clicking on the search next to the count.\r
82 \r
83 My use case of counting only unread messages (but still showing all of them,\r
84 like just about every other mail client out there) is an example of this.\r
85 But you're right that I can't think of any other examples (which is why I\r
86 suggested just baking this specific thing in earlier).\r
87 \r
88 > I'm somewhat indifferent, since I rarely use those links\r
89 > directly, so any more opinions on this are very much appreciated.\r
90 \r
91 Actually, here's a new thought that may help address your original problem\r
92 (assuming I understand it correctly now).  One of my design criteria for the\r
93 custom query parser (need to get back to those patches...) was to support\r
94 "implicit tag filters" such as hiding everything with tag:spam or tag:killed\r
95 (or tag:muted, etc) unless these tags are specifically requested by a\r
96 query.  That would apply equally to generated queries like the all tags\r
97 list, so you could filter out tag:killed messages centrally using a\r
98 mechanism like this, rather than having to work it in to every query\r
99 somehow.\r
100 \r
101 > > So, to me, it seems like this turns the all tags section into another\r
102 > > saved searches section, just with a slight twist, and makes me wonder\r
103 > > if there's a better way to reconcile these.\r
104 >\r
105 > Well, it already was sort of a non-configurable saved searches section\r
106 > before, so I didn't really turn it into one. :)\r
107 \r
108 True.\r
109 \r
110 > Since the main difference between those sections is the clear visual\r
111 > distinction, it might be an option to provide the user with functions to\r
112 > easily declare new sections for the hello screen, where this sort of\r
113 > thing is configurable. (One possible use that comes to mind would be to\r
114 > group tags into different categories.)\r
115 \r
116 That would be awesome.\r
117 \r
118 --00235429d2f4b72c0704a42565f4\r
119 Content-Type: text/html; charset=ISO-8859-1\r
120 Content-Transfer-Encoding: quoted-printable\r
121 \r
122 <p><br>\r
123 On May 25, 2011 7:21 PM, &quot;Daniel Schoepe&quot; &lt;<a href=3D"mailto:d=\r
124 aniel.schoepe@googlemail.com">daniel.schoepe@googlemail.com</a>&gt; wrote:<=\r
125 br>\r
126 &gt;<br>\r
127 &gt; On Wed, 25 May 2011 18:42:30 -0400, Austin Clements &lt;<a href=3D"mai=\r
128 lto:amdragon@mit.edu">amdragon@mit.edu</a>&gt; wrote:<br>\r
129 &gt; &gt; &#39;Doh. =A0That&#39;s what I get for not reading the surroundin=\r
130 g code. =A0I<br>\r
131 &gt; &gt; misunderstood what your patch was going for and assumed it was wh=\r
132 at<br>\r
133 &gt; &gt; *I* wanted notmuch to do, which is to show me useful counts (e.g.=\r
134 ,<br>\r
135 &gt; &gt; unread count), but not to change the underlying query. =A0]:--8)<=\r
136 br>\r
137 &gt;<br>\r
138 &gt; I thought about that too, but figured it should be rather rare that<br=\r
139 >\r
140 &gt; someone wants only a portion of some messages _counted_, but all<br>\r
141 &gt; displayed when clicking on the search next to the count.</p>\r
142 <p>My use case of counting only unread messages (but still showing all of t=\r
143 hem, like just about every other mail client out there) is an example of th=\r
144 is. But you&#39;re right that I can&#39;t think of any other examples (whic=\r
145 h is why I suggested just baking this specific thing in earlier).</p>\r
146 \r
147 <p>&gt; I&#39;m somewhat indifferent, since I rarely use those links<br>\r
148 &gt; directly, so any more opinions on this are very much appreciated.</p>\r
149 <p>Actually, here&#39;s a new thought that may help address your original p=\r
150 roblem (assuming I understand it correctly now).=A0 One of my design criter=\r
151 ia for the custom query parser (need to get back to those patches...) was t=\r
152 o support &quot;implicit tag filters&quot; such as hiding everything with t=\r
153 ag:spam or tag:killed (or tag:muted, etc) unless these tags are specificall=\r
154 y requested by a query.=A0 That would apply equally to generated queries li=\r
155 ke the all tags list, so you could filter out tag:killed messages centrally=\r
156  using a mechanism like this, rather than having to work it in to every que=\r
157 ry somehow.</p>\r
158 \r
159 <p>&gt; &gt; So, to me, it seems like this turns the all tags section into =\r
160 another<br>\r
161 &gt; &gt; saved searches section, just with a slight twist, and makes me wo=\r
162 nder<br>\r
163 &gt; &gt; if there&#39;s a better way to reconcile these.<br>\r
164 &gt;<br>\r
165 &gt; Well, it already was sort of a non-configurable saved searches section=\r
166 <br>\r
167 &gt; before, so I didn&#39;t really turn it into one. :)</p>\r
168 <p>True.</p>\r
169 <p>&gt; Since the main difference between those sections is the clear visua=\r
170 l<br>\r
171 &gt; distinction, it might be an option to provide the user with functions =\r
172 to<br>\r
173 &gt; easily declare new sections for the hello screen, where this sort of<b=\r
174 r>\r
175 &gt; thing is configurable. (One possible use that comes to mind would be t=\r
176 o<br>\r
177 &gt; group tags into different categories.)</p>\r
178 <p>That would be awesome.</p>\r
179 \r
180 --00235429d2f4b72c0704a42565f4--\r