1 Return-Path: <pieter@praet.org>
\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 92715429E26
\r
6 for <notmuch@notmuchmail.org>; Thu, 12 Jan 2012 09:09:55 -0800 (PST)
\r
7 X-Virus-Scanned: Debian amavisd-new at olra.theworths.org
\r
11 X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5
\r
12 tests=[RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled
\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 uUDElE5mJulG for <notmuch@notmuchmail.org>;
\r
16 Thu, 12 Jan 2012 09:09:55 -0800 (PST)
\r
17 Received: from mail-ww0-f45.google.com (mail-ww0-f45.google.com
\r
18 [74.125.82.45]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client
\r
19 certificate requested) by olra.theworths.org (Postfix) with ESMTPS id
\r
20 C0E70431FB6 for <notmuch@notmuchmail.org>; Thu, 12 Jan 2012 09:09:54 -0800
\r
22 Received: by wgbds11 with SMTP id ds11so1947514wgb.2
\r
23 for <notmuch@notmuchmail.org>; Thu, 12 Jan 2012 09:09:53 -0800 (PST)
\r
24 Received: by 10.181.13.208 with SMTP id fa16mr7786908wid.12.1326388193621;
\r
25 Thu, 12 Jan 2012 09:09:53 -0800 (PST)
\r
26 Received: from localhost ([109.131.126.209])
\r
27 by mx.google.com with ESMTPS id di5sm10055363wib.3.2012.01.12.09.09.52
\r
28 (version=TLSv1/SSLv3 cipher=OTHER);
\r
29 Thu, 12 Jan 2012 09:09:52 -0800 (PST)
\r
30 From: Pieter Praet <pieter@praet.org>
\r
31 To: Dmitry Kurochkin <dmitry.kurochkin@gmail.com>,
\r
32 David Bremner <david@tethera.net>, notmuch@notmuchmail.org
\r
33 Subject: Re: [PATCH v2] Output unmodified Content-Type header value for JSON
\r
35 In-Reply-To: <87obw6prpd.fsf@gmail.com>
\r
36 References: <1321659905-24367-1-git-send-email-dmitry.kurochkin@gmail.com>
\r
37 <1321676321-27745-1-git-send-email-dmitry.kurochkin@gmail.com>
\r
38 <87sjlktgi6.fsf@zancas.localnet> <87obw6prpd.fsf@gmail.com>
\r
39 User-Agent: Notmuch/0.10.2+115~gadd29f6 (http://notmuchmail.org) Emacs/23.3.1
\r
40 (x86_64-unknown-linux-gnu)
\r
41 Date: Thu, 12 Jan 2012 18:08:08 +0100
\r
42 Message-ID: <87fwfkluh3.fsf@praet.org>
\r
44 Content-Type: text/plain; charset=us-ascii
\r
45 X-BeenThere: notmuch@notmuchmail.org
\r
46 X-Mailman-Version: 2.1.13
\r
48 List-Id: "Use and development of the notmuch mail system."
\r
49 <notmuch.notmuchmail.org>
\r
50 List-Unsubscribe: <http://notmuchmail.org/mailman/options/notmuch>,
\r
51 <mailto:notmuch-request@notmuchmail.org?subject=unsubscribe>
\r
52 List-Archive: <http://notmuchmail.org/pipermail/notmuch>
\r
53 List-Post: <mailto:notmuch@notmuchmail.org>
\r
54 List-Help: <mailto:notmuch-request@notmuchmail.org?subject=help>
\r
55 List-Subscribe: <http://notmuchmail.org/mailman/listinfo/notmuch>,
\r
56 <mailto:notmuch-request@notmuchmail.org?subject=subscribe>
\r
57 X-List-Received-Date: Thu, 12 Jan 2012 17:09:55 -0000
\r
59 On Sun, 20 Nov 2011 22:35:42 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:
\r
60 > On Sat, 19 Nov 2011 08:59:29 -0400, David Bremner <david@tethera.net> wrote:
\r
61 > > On Sat, 19 Nov 2011 08:18:41 +0400, Dmitry Kurochkin <dmitry.kurochkin@gmail.com> wrote:
\r
62 > > > Before the change, notmuch used g_mime_content_type_to_string(3)
\r
63 > > > function to output Content-Type header value. Turns out it outputs
\r
64 > > > only "type/subtype" part and ignores all parameters. Also, if there
\r
65 > > > is no Content-Type header, default "text/plain" value is used.
\r
69 > > I haven't analyzed the substance of your patch yet, but I did have a
\r
70 > > couple thoughts while reading your mail.
\r
72 > > - It seems that every time we change the json format, we have a round of
\r
73 > > suffering because people are unable to detect a mismatch between their
\r
74 > > emacs code and the cli. Not that this is your problem necessarily, but
\r
75 > > it would be nice if someone (TM), would come up with some version info
\r
76 > > for the json output, and a patch to check it on the emacs side.
\r
79 > IMO this is a good idea.
\r
81 > > - The previous point is a bit of a counterargument to this, but in
\r
82 > > general, I think I prefer patches that modify the core seperate from
\r
83 > > those that do emacs (or python, or ...) stuff.
\r
86 > I couls separate it. I made is a single patch to avoid having a
\r
87 > revision with broken emacs UI (and tests).
\r
90 I'd like to propose to always apply patch series on a *topic* branch
\r
91 which would then be merged back into 'master', thus avoiding this issue
\r
92 altogether whilst making it more obvious which patches belong together
\r
93 (eg. for easier cross-referencing with the ML).
\r
98 > > - I understand you want to make your patches reviewable without applying
\r
99 > > by including lots of context, but at a certain point it has actually
\r
100 > > the opposite effect for me. I just don't read 900+ line emails ;). Of
\r
101 > > course, I can still apply the patch and look at it, so it's really up
\r
105 > _______________________________________________
\r
106 > notmuch mailing list
\r
107 > notmuch@notmuchmail.org
\r
108 > http://notmuchmail.org/mailman/listinfo/notmuch
\r