[PATCH] convert bitmap to unsigned char
[notmuch-archives.git] / c4 / 4f014f05cdcd60b1833e8dab7208f973165af9
1 Return-Path: <m.walters@qmul.ac.uk>\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 A5B16431FB6\r
6         for <notmuch@notmuchmail.org>; Thu,  5 Jul 2012 01:47: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.401\r
10 X-Spam-Level: *\r
11 X-Spam-Status: No, score=1.401 tagged_above=-999 required=5\r
12         tests=[DKIM_ADSP_CUSTOM_MED=0.001, FREEMAIL_FROM=0.001,\r
13         FREEMAIL_REPLY=2.499, NML_ADSP_CUSTOM_MED=1.2, RCVD_IN_DNSWL_MED=-2.3]\r
14         autolearn=disabled\r
15 Received: from olra.theworths.org ([127.0.0.1])\r
16         by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024)\r
17         with ESMTP id ZB94zguvTeMO for <notmuch@notmuchmail.org>;\r
18         Thu,  5 Jul 2012 01:47:49 -0700 (PDT)\r
19 Received: from mail2.qmul.ac.uk (mail2.qmul.ac.uk [138.37.6.6])\r
20         (using TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits))\r
21         (No client certificate requested)\r
22         by olra.theworths.org (Postfix) with ESMTPS id D7255431FAE\r
23         for <notmuch@notmuchmail.org>; Thu,  5 Jul 2012 01:47:48 -0700 (PDT)\r
24 Received: from smtp.qmul.ac.uk ([138.37.6.40])\r
25         by mail2.qmul.ac.uk with esmtp (Exim 4.71)\r
26         (envelope-from <m.walters@qmul.ac.uk>)\r
27         id 1Smhj1-0004Cd-1B; Thu, 05 Jul 2012 09:47:47 +0100\r
28 Received: from 94-192-233-223.zone6.bethere.co.uk ([94.192.233.223]\r
29         helo=localhost)\r
30         by smtp.qmul.ac.uk with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.69)\r
31         (envelope-from <m.walters@qmul.ac.uk>)\r
32         id 1Smhj0-0004yw-Py; Thu, 05 Jul 2012 09:47:46 +0100\r
33 From: Mark Walters <markwalters1009@gmail.com>\r
34 To: Peter Wang <novalazy@gmail.com>,\r
35         Jameson Graef Rollins <jrollins@finestructure.net>\r
36 Subject: Re: [PATCH 2/3] show: output Reply-To headers\r
37 In-Reply-To: <20120704182459.GI2342@hili.localdomain>\r
38 References: <1340508470-16606-1-git-send-email-novalazy@gmail.com>\r
39         <1340508470-16606-2-git-send-email-novalazy@gmail.com>\r
40         <87vci471tw.fsf@servo.finestructure.net>\r
41         <20120704115951.GC2342@hili.localdomain>\r
42         <87pq8c6zad.fsf@servo.finestructure.net>\r
43         <20120704182459.GI2342@hili.localdomain>\r
44 User-Agent: Notmuch/0.13.2+70~gb6a56e7 (http://notmuchmail.org) Emacs/23.4.1\r
45         (x86_64-pc-linux-gnu)\r
46 Date: Thu, 05 Jul 2012 09:47:43 +0100\r
47 Message-ID: <87vci2egr4.fsf@qmul.ac.uk>\r
48 MIME-Version: 1.0\r
49 Content-Type: text/plain; charset=us-ascii\r
50 X-Sender-Host-Address: 94.192.233.223\r
51 X-QM-SPAM-Info: Sender has good ham record.  :)\r
52 X-QM-Body-MD5: f45152b962d9d74d44f59f508694b975 (of first 20000 bytes)\r
53 X-SpamAssassin-Score: -1.2\r
54 X-SpamAssassin-SpamBar: -\r
55 X-SpamAssassin-Report: The QM spam filters have analysed this message to\r
56         determine if it is\r
57         spam. We require at least 5.0 points to mark a message as spam.\r
58         This message scored -1.2 points.\r
59         Summary of the scoring: \r
60         * -2.3 RCVD_IN_DNSWL_MED RBL: Sender listed at http://www.dnswl.org/,\r
61         *      medium trust\r
62         *      [138.37.6.40 listed in list.dnswl.org]\r
63         * 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail\r
64         provider *      (markwalters1009[at]gmail.com)\r
65         * -0.0 T_RP_MATCHES_RCVD Envelope sender domain matches handover relay\r
66         *      domain\r
67         *  1.0 FREEMAIL_REPLY From and body contain different freemails\r
68         *  0.1 AWL AWL: From: address is in the auto white-list\r
69 X-QM-Scan-Virus: ClamAV says the message is clean\r
70 Cc: notmuch@notmuchmail.org\r
71 X-BeenThere: notmuch@notmuchmail.org\r
72 X-Mailman-Version: 2.1.13\r
73 Precedence: list\r
74 List-Id: "Use and development of the notmuch mail system."\r
75         <notmuch.notmuchmail.org>\r
76 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,\r
77         <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>\r
78 List-Archive: <http://notmuchmail.org/pipermail/notmuch>\r
79 List-Post: <mailto:notmuch@notmuchmail.org>\r
80 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>\r
81 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,\r
82         <mailto:notmuch-request@notmuchmail.org?subject=subscribe>\r
83 X-List-Received-Date: Thu, 05 Jul 2012 08:47:49 -0000\r
84 \r
85 On Wed, 04 Jul 2012, Peter Wang <novalazy@gmail.com> wrote:\r
86 > On Tue, 03 Jul 2012 19:22:18 -0700, Jameson Graef Rollins <jrollins@finestructure.net> wrote:\r
87 >> On Tue, Jul 03 2012, Peter Wang <novalazy@gmail.com> wrote:\r
88 >> > I want to see what the sender intended, before hitting reply.\r
89 >> \r
90 >> Given that there have been requests to see a lot of other headers as\r
91 >> well, we probably need to have a discussion about which ones are worth\r
92 >> of emitting, and how we give the user some more general control to see\r
93 >> the ones they want.  Either that or we just emit them all?\r
94 >\r
95 > If we start with the obvious:\r
96 >\r
97 >   notmuch show --output-headers=date,from,subject,to,cc,reply-to ...\r
98 >\r
99 > with the default being the current set.\r
100 >\r
101 > Emitting everything would be easier but seems wasteful.  I just looked\r
102 > at a random message: in RFC822 syntax the header is 4073 bytes, and the\r
103 > body is 1116 bytes.  Keeping only the fields that notmuch emits reduces\r
104 > the header to 295 bytes.  Reply-To is 92 bytes, but not every message\r
105 > has that.\r
106 \r
107 I wonder if it would make sense for this option to be combined with\r
108 something like\r
109 id:"1341041595-5858-1-git-send-email-markwalters1009@gmail.com" which\r
110 chooses whether to output the body of the message or not.\r
111 \r
112 Maybe something like --output=short|medium|full\r
113 with short being just the brief headers, medium being the current\r
114 default of brief headers and text bodies, and full being message with\r
115 all headers.\r
116 \r
117 I am not sure I like it (as someone will want full headers and no\r
118 bodies!) but we don't want the command line to get too cluttered.\r
119 \r
120 Another possibility for this particular choice: could a list of wanted\r
121 headers be included in the config file? Since I think you want it for\r
122 "user wants to see it" reasons rather than "program needs it to do\r
123 something" reasons that might make sense.\r
124 \r
125 Best wishes\r
126 \r
127 Mark\r
128 \r