From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from localhost (localhost [127.0.0.1]) by olra.theworths.org (Postfix) with ESMTP id 087BB431FAF for ; Sun, 5 Feb 2012 11:52:13 -0800 (PST) X-Virus-Scanned: Debian amavisd-new at olra.theworths.org X-Spam-Flag: NO X-Spam-Score: -0.799 X-Spam-Level: X-Spam-Status: No, score=-0.799 tagged_above=-999 required=5 tests=[DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_LOW=-0.7] autolearn=disabled Received: from olra.theworths.org ([127.0.0.1]) by localhost (olra.theworths.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 5198o+dzrGDR for ; Sun, 5 Feb 2012 11:52:12 -0800 (PST) Received: from mail-bk0-f53.google.com (mail-bk0-f53.google.com [209.85.214.53]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client certificate requested) by olra.theworths.org (Postfix) with ESMTPS id 21E3C431FAE for ; Sun, 5 Feb 2012 11:52:11 -0800 (PST) Received: by bke11 with SMTP id 11so4925941bke.26 for ; Sun, 05 Feb 2012 11:52:10 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=gamma; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-type:content-transfer-encoding; bh=ngOciv8MFJyyqKfFxzeWpOEXD1iwrXi4HNeQo6Dj1/g=; b=muewf+844rg21ojXS+qFy8I/t4w38rB0xXypTgY99A3ih+801aIq5TpR/EB1JkZyoc K1erBZmPFln7/EqkGeCrzMFe5LlN7SRh3295PWIjPyipIS9RwB5s/Kc9Q7FJ25MiDl4m XNzAFcpMa1s1Ex7IGPmbH7Ozb4Zc+K7vfPuM8= Received: by 10.204.151.77 with SMTP id b13mr7340295bkw.57.1328471530655; Sun, 05 Feb 2012 11:52:10 -0800 (PST) Received: from localhost ([91.144.186.21]) by mx.google.com with ESMTPS id 20sm38023985bkr.0.2012.02.05.11.52.09 (version=TLSv1/SSLv3 cipher=OTHER); Sun, 05 Feb 2012 11:52:10 -0800 (PST) From: Dmitry Kurochkin To: Adam Wolfe Gordon , Mark Walters Subject: Re: [PATCH v3 2/5] reply: Add a JSON reply format. In-Reply-To: References: <1326995217-27423-1-git-send-email-awg+notmuch@xvx.ca> <1326995217-27423-3-git-send-email-awg+notmuch@xvx.ca> <87mx8xpki3.fsf@qmul.ac.uk> User-Agent: Notmuch/0.11+139~gd9b7cab (http://notmuchmail.org) Emacs/23.3.1 (x86_64-pc-linux-gnu) Date: Sun, 05 Feb 2012 23:50:54 +0400 Message-ID: <87aa4xys81.fsf@gmail.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Cc: notmuch@notmuchmail.org X-BeenThere: notmuch@notmuchmail.org X-Mailman-Version: 2.1.13 Precedence: list List-Id: "Use and development of the notmuch mail system." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 05 Feb 2012 19:52:13 -0000 On Sun, 5 Feb 2012 12:42:12 -0700, Adam Wolfe Gordon w= rote: > Thanks for the review. The style nits are things I missed in my > previous cleanup, so thanks for pointing them out. I should probably > run uncrustify and see if it complains about anything else. >=20 > The other points are definitely up for discussion, and some are areas > where I was unsure to start with. Discussion inline: >=20 > On Sun, Feb 5, 2012 at 04:50, Mark Walters wr= ote: > >> + =C2=A0 =C2=A0/* We only care about inline text parts for reply purpo= ses */ > >> + =C2=A0 =C2=A0if (reply_check_part_type (part, "text", "*", GMIME_DIS= POSITION_INLINE)) { > > > > This seems to be different from the logic in the text output: I think > > that inlines all text/* regardless of disposition. I think the JSON > > output should include at least as much as the text output as it is easy > > for the caller to discard parts. >=20 > Indeed, the text output includes all text/* parts except for > text/html, regardless of disposition. My thought was that it doesn't > really make sense to quote an attachment, or at least it's not the > behavior I would expect. But, perhaps it makes more sense to include > all the text parts, with their dispositions, and let the MUA decide > what it wants to quote. If anyone has thoughts on this I'm happy to > hear them. >=20 > > Does wrapper need to a free/unref somewhere? >=20 > The text format doesn't free or unref wrapper, so I followed its > example. But, I'm not a gmime expert, and I agree intuitively that it > should be freed somehow. Can anyone enlighten me? >=20 > > If replying to multiple messages (such as a whole thread) you get > > multiple sets of "new headers". I think that probably is not what is > > wanted but its still better than the weird things the text version > > does. Might be worth putting a comment. [What I think should happen is > > that a union of all the headers from all these is taken throwing away > > duplicate addresses but that is obviously not part of this patch set] >=20 > I've never been sure about what the intended behavior is when replying > to multiple messages in the CLI. My thought was that it should create > a reply to each message, so an MUA could iterate over them allowing > you to compose replies to multiple messages. But, I've never wanted or > used such a feature, so I'm agnostic on whether it's right. The emacs > MUA (at least with my patch) ignores all but the first reply object in > the array, my assumption being that reply only operates on multiple > messages by accident. >=20 In some cases, notmuch CLI insists that the search query matches exactly one message (e.g. notmuch show for parts). IMO the same behavior makes sense for notmuch reply. Regards, Dmitry > Does anyone use reply with multiple messages? If so, what semantics do > you expect? > _______________________________________________ > notmuch mailing list > notmuch@notmuchmail.org > http://notmuchmail.org/mailman/listinfo/notmuch