From 76d3ee40a7c0d512bf55eafa802ded9f791a1675 Mon Sep 17 00:00:00 2001 From: David Edmondson Date: Mon, 12 May 2014 07:06:00 +0100 Subject: [PATCH] Re: [PATCH v2] emacs: Improve the cited message included in replies --- fb/ccd1e5c7d9eef5c1722cff74f576ddd64ece1b | 149 ++++++++++++++++++++++ 1 file changed, 149 insertions(+) create mode 100644 fb/ccd1e5c7d9eef5c1722cff74f576ddd64ece1b diff --git a/fb/ccd1e5c7d9eef5c1722cff74f576ddd64ece1b b/fb/ccd1e5c7d9eef5c1722cff74f576ddd64ece1b new file mode 100644 index 000000000..87597a8e8 --- /dev/null +++ b/fb/ccd1e5c7d9eef5c1722cff74f576ddd64ece1b @@ -0,0 +1,149 @@ +Return-Path: +X-Original-To: notmuch@notmuchmail.org +Delivered-To: notmuch@notmuchmail.org +Received: from localhost (localhost [127.0.0.1]) + by olra.theworths.org (Postfix) with ESMTP id 1EB29431FC0 + for ; Sun, 11 May 2014 23:06:18 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: -0.7 +X-Spam-Level: +X-Spam-Status: No, score=-0.7 tagged_above=-999 required=5 + tests=[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 ViCgchGQY30Q for ; + Sun, 11 May 2014 23:06:10 -0700 (PDT) +Received: from mail-wg0-f47.google.com (mail-wg0-f47.google.com + [74.125.82.47]) (using TLSv1 with cipher RC4-SHA (128/128 bits)) (No client + certificate requested) by olra.theworths.org (Postfix) with ESMTPS id + 15753431FBF for ; Sun, 11 May 2014 23:06:09 -0700 + (PDT) +Received: by mail-wg0-f47.google.com with SMTP id x12so6389415wgg.30 + for ; Sun, 11 May 2014 23:06:08 -0700 (PDT) +X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; + d=1e100.net; s=20130820; + h=x-gm-message-state:to:subject:in-reply-to:references:user-agent + :from:date:message-id:mime-version:content-type; + bh=xKgfVMpY/eCb2lVDCI5gICXdJKVtKQ9motlajydGzzA=; + b=H3aC4QWbEvj7RFECdSSHaVMgzFvqy4bHBRLLvpgETjxrCVG/G20ii08QjC+uyse47J + tn1v2w5LWx0+E35qA4tXgiqoDQY5QWo5sYiMF/TRGkM60K2G0usjL/yZBsvnjV/eKjMv + kNFxPDzTH6uC5k4rAuK1fuKWvnRt6g6vOvKcYpQWJ46gPZQCeHp0poCn4d3XLAQxvj05 + eia0jPM5QC7JuHamsHsknruP83ZSvGgzWtaN+5sFBBVYFzJw0Y9P2fLZRB8LQKk+NQq3 + mVCPDli2DUPLOSYSJreOWuCGxIttFMgejnMf3TK2Zoa0JetZWqvECPNhwAdzYnQRXYJ/ + tbHg== +X-Gm-Message-State: + ALoCoQmUoJ1u980KH9gqoU2UmyGeXJMntL96GTfAN1y+Cwcjor4TV3MqUzMgpAfGJpFsaG4WYNtm +X-Received: by 10.180.11.239 with SMTP id t15mr14066263wib.25.1399874768604; + Sun, 11 May 2014 23:06:08 -0700 (PDT) +Received: from localhost ([2a01:348:1a2:1:a288:b4ff:fe8a:77d8]) + by mx.google.com with ESMTPSA id + xm20sm14171402wib.19.2014.05.11.23.06.05 for + (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); + Sun, 11 May 2014 23:06:06 -0700 (PDT) +To: Mark Walters , notmuch@notmuchmail.org +Subject: Re: [PATCH v2] emacs: Improve the cited message included in replies +In-Reply-To: <87ha4y8286.fsf@qmul.ac.uk> +References: <1399482846-25308-1-git-send-email-dme@dme.org> + <1399530272-11857-1-git-send-email-dme@dme.org> + <87ha4y8286.fsf@qmul.ac.uk> +User-Agent: Notmuch/0.18 (http://notmuchmail.org) Emacs/24.3.1 + (x86_64-pc-linux-gnu) +From: David Edmondson +Date: Mon, 12 May 2014 07:06:00 +0100 +Message-ID: +MIME-Version: 1.0 +Content-Type: multipart/signed; boundary="=-=-="; + micalg=pgp-sha1; protocol="application/pgp-signature" +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: Mon, 12 May 2014 06:06:18 -0000 + +--=-=-= +Content-Type: text/plain + +On Sat, May 10 2014, Mark Walters wrote: +> On Thu, 08 May 2014, David Edmondson wrote: +>> emacs: Improve the cited message included in replies +>> +>> v2: +>> - Don't run the text/plain hooks when generating the message to quote. +>> +> +> In principle I like this approach: keeping show and reply closely linked +> seems good. +> +> At the moment, as you say, the tests don't all pass. The first reason is +> that this puts in buttons for the parts. Stopping that happening is not +> completely trivial as we need to make sure that the instruction gets +> passed down to sub-parts of multiparts etc. (You could argue that the +> 'no-button option to notmuch-show-insert-bodypart is buggy as it only +> stops the top level button for the part) + +That seems straightforward. I was sure that there was a variable listing +part types that didn't require buttons (which could be let-bound), but I +must have been imagining it. + +Inserting the button text for the trivial case (single text/plain part) +is already special-cased in the show code. In the case where only a +single part is being shown (e.g. multipart/alternative with text/plain +and text/html with the text/html hidden) it would make sense _not_ to +show the button text. For more complex messages (e.g. multipart/mixed +with text/plain and message/rfc822, where the message/rfc822 contains +multiple parts), showing the button text seems useful to allow the +different sub-sections of the reply to be distinguished. + +Perhaps there is an approach based on the complexity of the quoted +message that should determine whether the button text is inserted (which +might also apply (in modified form?) in normal message display)? Normal +message display has to allow for some interaction with the parts +(show/hide, etc.), which doesn't apply to citation. + +> Secondly, the existing code only includes text sub-parts of the +> message. I would think your version might include any sub-parts show is +> configured to display, including, say images. (However, in my testing +> images didn't seem to be included: I am not sure why.) + +Eek. + +Inserting the images in the reply buffer itself would not be +difficult. What should happen when the user hits 'send'? We currently +don't have a composition mode that would allow us to generate useful +output in that case. Adding one feels like a lot of work. In many cases +it would be necessary to transform the message into HTML to properly +represent the content. + +MML (the markup used in `message-mode') is really not designed for +something this complex. + +> I can't tell how much work it is to modify show to take account of these +> things, so am not sure if this is the best approach, or just adding +> something to deal with rfc822 to our existing reply code is easier. + +The approach in this patch mostly involves removing code - adding +special case code to notmuch-mua.el to support message/rfc822 involves +_adding_ a bunch more complex code (I tried that first). + +--=-=-= +Content-Type: application/pgp-signature; name="signature.asc" + +-----BEGIN PGP SIGNATURE----- +Version: GnuPG v1 + +iKYEARECAGYFAlNwZMlfFIAAAAAALgAoaXNzdWVyLWZwckBub3RhdGlvbnMub3Bl +bnBncC5maWZ0aGhvcnNlbWFuLm5ldDc1M0Y5NDJDMEExNjc3MDE4OURGMUYyMDY5 +RUNEMEFCRjA0OTY1MTYACgkQaezQq/BJZRbo+wCeOQqTZtDN557pZ5U2mMiIB+ce +zJUAnRlQ9BRdK92ajo525yIp3QPOwxxI +=Kvgj +-----END PGP SIGNATURE----- +--=-=-=-- -- 2.26.2