From dc28e20219210ac1e550d4b80d102dc1cf81b4d3 Mon Sep 17 00:00:00 2001 From: Eric Abrahamsen Date: Tue, 27 Aug 2013 22:41:45 +0800 Subject: [PATCH] Re: encoding when forwarding messages --- 4e/459c811cf1e3a782aebfadcec73c3d1cdd7ce6 | 99 +++++++++++++++++++++++ 1 file changed, 99 insertions(+) create mode 100644 4e/459c811cf1e3a782aebfadcec73c3d1cdd7ce6 diff --git a/4e/459c811cf1e3a782aebfadcec73c3d1cdd7ce6 b/4e/459c811cf1e3a782aebfadcec73c3d1cdd7ce6 new file mode 100644 index 000000000..abdd2e327 --- /dev/null +++ b/4e/459c811cf1e3a782aebfadcec73c3d1cdd7ce6 @@ -0,0 +1,99 @@ +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 D0E86431FD4 + for ; Tue, 27 Aug 2013 07:41:19 -0700 (PDT) +X-Virus-Scanned: Debian amavisd-new at olra.theworths.org +X-Spam-Flag: NO +X-Spam-Score: 0.865 +X-Spam-Level: +X-Spam-Status: No, score=0.865 tagged_above=-999 required=5 + tests=[RCVD_IN_DNSWL_NONE=-0.0001, RCVD_NUMERIC_HELO=0.865] + 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 lDPiIEwjzjVG for ; + Tue, 27 Aug 2013 07:41:12 -0700 (PDT) +Received: from plane.gmane.org (plane.gmane.org [80.91.229.3]) + (using TLSv1 with cipher AES256-SHA (256/256 bits)) + (No client certificate requested) + by olra.theworths.org (Postfix) with ESMTPS id 56F27431FAF + for ; Tue, 27 Aug 2013 07:41:12 -0700 (PDT) +Received: from list by plane.gmane.org with local (Exim 4.69) + (envelope-from ) id 1VEKSC-0007tJ-E3 + for notmuch@notmuchmail.org; Tue, 27 Aug 2013 16:41:08 +0200 +Received: from 114.252.248.167 ([114.252.248.167]) + by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) + id 1AlnuQ-0007hv-00 + for ; Tue, 27 Aug 2013 16:41:08 +0200 +Received: from eric by 114.252.248.167 with local (Gmexim 0.1 (Debian)) + id 1AlnuQ-0007hv-00 + for ; Tue, 27 Aug 2013 16:41:08 +0200 +X-Injected-Via-Gmane: http://gmane.org/ +To: notmuch@notmuchmail.org +From: Eric Abrahamsen +Subject: Re: encoding when forwarding messages +Date: Tue, 27 Aug 2013 22:41:45 +0800 +Lines: 37 +Message-ID: <87fvtvi4ba.fsf@ericabrahamsen.net> +References: <87bo4jjv15.fsf@ericabrahamsen.net> + <87y57n8jmd.fsf@zancas.localnet> +Mime-Version: 1.0 +Content-Type: text/plain +X-Complaints-To: usenet@ger.gmane.org +X-Gmane-NNTP-Posting-Host: 114.252.248.167 +User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (gnu/linux) +Cancel-Lock: sha1:xtidThf1aMewpXWBSG6ilW6PstY= +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: Tue, 27 Aug 2013 14:41:20 -0000 + +David Bremner writes: + +> Eric Abrahamsen writes: +> +>> I saw another message about the same problem on this list, in January, +>> with the advice to upgrade to git, but I'm still seeing it on notmuch +>> 0.16+7~gdc51bf0. Forwarding a message from within emacs using +>> `notmuch-mua-forward-message' sometimes produces garbled encoding. +>> Calling `notmuch-show-forward-message' on the same message, however, +>> creates what appears to be a raw message, properly encoded. +>> +>> Is there something still amiss in the code? Am I using the wrong +>> command? +> +> Do you really mean notmuch-mua-forward-message? That function is not +> interactive, which would make it more work to call. +> +> In any case, notmuch-show-forward-message does take some care to read +> the message in raw mode (via with-current-notmuch-show-message); when +> you call notmuch-mua*forward-message, how are you filling the buffer? +> +> d + +Sorry! It was `notmuch-mua-new-forward-message' I've been using, +apologies for the confusion. I'm not calling any particular filling +commands. I've got this in .gnus.el: + +(add-hook 'message-mode-hook + (lambda () + (flyspell-mode) + (orgstruct-mode))) + +And I've got the auto-fill minor mode enabled. I don't see any other +minor modes that seem likely to interfere... + +Thanks! +Eric + -- 2.26.2