From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.io/gmane.emacs.gnus.general/37538 Path: main.gmane.org!not-for-mail From: Simon Josefsson Newsgroups: gmane.emacs.gnus.general Subject: Re: "> > >" space removal removes too many spaces? Date: Sun, 05 Aug 2001 21:30:32 +0200 Message-ID: References: <878zgy62mg.fsf@deneb.enyo.de> <87g0b64l87.fsf@deneb.enyo.de> NNTP-Posting-Host: coloc-standby.netfonds.no Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1035172936 14416 80.91.224.250 (21 Oct 2002 04:02:16 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Mon, 21 Oct 2002 04:02:16 +0000 (UTC) Cc: ding@gnus.org Return-Path: Return-Path: Original-Received: (qmail 3924 invoked from network); 5 Aug 2001 19:29:17 -0000 Original-Received: from dolk.extundo.com (195.42.214.242) by gnus.org with SMTP; 5 Aug 2001 19:29:17 -0000 Original-Received: from barbar.josefsson.org (slipsten.extundo.com [195.42.214.241]) (authenticated) by dolk.extundo.com (8.11.3/8.11.3) with ESMTP id f75JTNw16199; Sun, 5 Aug 2001 21:29:24 +0200 Original-To: Florian Weimer In-Reply-To: <87g0b64l87.fsf@deneb.enyo.de> (Florian Weimer's message of "Sun, 05 Aug 2001 16:47:36 +0200") Mail-Copies-To: nobody User-Agent: Gnus/5.090004 (Oort Gnus v0.04) Emacs/21.0.104 Original-Lines: 52 Xref: main.gmane.org gmane.emacs.gnus.general:37538 X-Report-Spam: http://spam.gmane.org/gmane.emacs.gnus.general:37538 Florian Weimer writes: > Simon Josefsson writes: > >>> '>' may appear at the beginning of a line accidently, and we certainly >>> want to supply the space character in this case. >> >> First, wouldn't it be very complicated to solve your case? > > No, I don't think so. I think it helps to consider a leading '>' to > be a quote character only if the preceding line is empty (or consists > entirely of whitespace), or if it starts in turn with a '>'. Ah. It's not a complete solution then, but probably covers enough cases to be worth it. > I've just implemented this logic (at least I think so). Looks nice. >> I don't see how you programatically can easily separate your case >> from e.g. >> >>> According to your analysis >>>>42 is a nice number >>> you indicate that 42 is a nice number. >> >> but suggestions are welcome. :) > > Not leaving blank lines before and after quotes is not my preferred > style of writing messages. ;-) Mine neither, but I see it from time to time. >> Secondly, RFC 2646 compliant MUAs should never generate this case in >> the first place. Even if you don't generate RFC 2646 (Gnus doesn't) >> you could QP encode the character to prevent the ambiguity. > > Does RFC 2646 really try to solve the problem this way? In this > case, the RFC is horribly broken. Attaching semantic to QP encoding > vs. not-encoding is clearly an extremely bad idea, and it certainly > contradicts the spirit of MIME. No, I think that approach is suggested in a couple of places, RFC 2015 being the only one I can find now (they use it to protect "From"). RFC 2646 suggests an alternate approach, space-stuffing the lines. It might be cleaner, but it's (slightly) less visually pleasing to non-RFC 2646 clients. The idea above looks good on all clients that support QP. The semantic of QP encoding vs unencoded is only in the generating client, the receiver doesn't care.