From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/54536 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: Charset encoding brokenness Date: Wed, 29 Oct 2003 22:30:15 +0100 Sender: ding-owner@lists.math.uh.edu Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1067463046 12929 80.91.224.253 (29 Oct 2003 21:30:46 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 29 Oct 2003 21:30:46 +0000 (UTC) Original-X-From: ding-owner+M3077@lists.math.uh.edu Wed Oct 29 22:30:43 2003 Return-path: Original-Received: from malifon.math.uh.edu ([129.7.128.13]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AExtq-0006lQ-00 for ; Wed, 29 Oct 2003 22:30:43 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.math.uh.edu) by malifon.math.uh.edu with smtp (Exim 3.20 #1) id 1AExti-0005Di-00; Wed, 29 Oct 2003 15:30:34 -0600 Original-Received: from justine.libertine.org ([66.139.78.221]) by malifon.math.uh.edu with esmtp (Exim 3.20 #1) id 1AExtd-0005Dd-00 for ding@lists.math.uh.edu; Wed, 29 Oct 2003 15:30:29 -0600 Original-Received: from yxa.extundo.com (178.230.13.217.in-addr.dgcsystems.net [217.13.230.178]) by justine.libertine.org (Postfix) with ESMTP id 957EE3A0080 for ; Wed, 29 Oct 2003 15:30:25 -0600 (CST) Original-Received: from latte (yxa.extundo.com [217.13.230.178]) (authenticated bits=0) by yxa.extundo.com (8.12.10/8.12.10) with ESMTP id h9TLUN1e022141 for ; Wed, 29 Oct 2003 22:30:24 +0100 Original-To: ding@gnus.org Mail-Copies-To: nobody X-Payment: hashcash 1.2 0:031029:ding@gnus.org:fc668eb48a6113c2 X-Hashcash: 0:031029:ding@gnus.org:fc668eb48a6113c2 In-Reply-To: (Jesper Harder's message of "Tue, 28 Oct 2003 04:01:22 +0100") User-Agent: Gnus/5.1003 (Gnus v5.10.3) Emacs/21.3.50 (gnu/linux) Precedence: bulk Xref: main.gmane.org gmane.emacs.gnus.general:54536 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:54536 Jesper Harder writes: > So the question is: how to forward/digest/etc correctly without > converting to mml? > > I think `mime-to-mml' is the wrong thing for most purposes for a > variety of reasons: > > 1. When I ask someone to forward a message, I usually want a > _verbatim_ copy, not an interpretation by Gnus. > > 2. `mime-to-mml' assumes that the message is actually valid MIME. > > 3. It's broken for pgp/mime. > > The last problem could probably be fixed by some special-casing. But > the other two remain. Yes; mime-to-mml shouldn't be used unless MML will be shown in the forwarded message buffer. The C-c C-f docstring is quite disappointing, so I experimented some, and I came up with more detailed descriptions of the modes: if ARG is nil, If m-f-a-m=t and m-f-s-m=best, this selects between ARG=2 and ARG=3 below depending on if MML is safe. I haven't thought through what it should do for the remaining 2*3-1=5 cases. if ARG is 1, "Gnus specific ASCII purist". This wrap a MML decoded message in a ASCII header/footer. I can't begin to understand why anyone would want this. For any non-trivial MIME message, I doubt any MUA but Gnus would render this in any understandable way. if ARG is 2, "MIME purist". Wrap raw body in MML application/rfc822 part. No MML decoding within body. if ARG is 3, "MML purist". Wrap MML-decoded body in MML application/rfc822 part. if ARG is 4, "ASCII purist in debug mode". Wrap gnus-original-article-buffer within ASCII forward headers. if ARG is 5 (not currently supported) "Forward-What-I-See, ASCII purist". This should use whatever is in the Gnus *Article* buffer. It should NOT try to decode the message in gnus-original-article-buffer again. No MML tags whatsoever, the forward header should be pure ASCII. The problem in implementing 5 appear to be getting the *Article* buffer down into message.el, since currently it only has access to gnus-original-article-buffer which isn't sufficient. We might consider swapping ARG=1 and ARG=5, since the ARG=1 above is quite weird, but this wouldn't be backwards compatible so maybe we shouldn't. Of course, then there is the problem of \345 characters instead of decoded data. Will think about that once I understand more.