Bug 110704 - Wrong quoting with quotesign ">%_"
Summary: Wrong quoting with quotesign ">%_"
Status: RESOLVED FIXED
Alias: None
Product: kmail
Classification: Applications
Component: general (show other bugs)
Version: 1.8.2
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: kdepim bugs
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2005-08-13 17:08 UTC by René Fischer
Modified: 2009-12-21 21:22 UTC (History)
3 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description René Fischer 2005-08-13 17:08:58 UTC
Version:           1.8.2 (using KDE 3.4.2, Kubuntu Package 4:3.4.2-0ubuntu0hoary2 )
Compiler:          gcc version 3.3.5 (Debian 1:3.3.5-8ubuntu2)
OS:                Linux (i686) release 2.6.10-5-386

KMail doesn't insert the correct quoting sign for 2nd level quotes (and up). KMail will always insert an additional blank after the ">". Take a look at the following examples:

Quote sign ">%_" (or "> ")
> > Quotelevel 2
> Quotelevel 1
My text

Quote sign ">"
>>Quotelevel 2
>Quotelevel 1
My text

But it should look like:
>> Quotelevel 2
> Quotelevel 1
My text

Can you please fix this, or implement an option to generate quotes like this? TIA
Comment 1 René Fischer 2005-11-03 07:51:42 UTC
In short: Take a look at the correct quoting function from KNode, where it works perferctly.
Comment 2 Carlos Diener 2005-11-03 16:40:12 UTC
*** This bug has been confirmed by popular vote. ***
Comment 3 Boyd Stephen Smith Jr. 2006-09-13 02:30:48 UTC
I'm not sure if the behavior the reporter wants is "correct".  I'd want to see some RFC (even if it's just informational) that supports that assertion.  However, I do think it would be a nice feature even if it's just something like adding a new special character to quotesign like "%-": inserts a space, unless immediately before quoted text.
Comment 4 René Fischer 2006-09-30 18:49:54 UTC
Maybe http://www.ietf.org/rfc/rfc2646.txt?
Comment 5 Boyd Stephen Smith Jr. 2006-10-04 23:56:58 UTC
RFC 2646 (link in comment #4) is only tangentially about quoting, and specifically about the format=flowed option to text/plain MIME parts in email.  That said, it does provide some useful examples, but (or may not) be applicable.

When considering that RFC, we need to keep in mind that it implicitly assumes that all messages use a single '>' as the quote sign, but does not mandate it. The ABNF in section 5, specifically line 589, makes this assumption explicit; direct application of the standard it therefore only applicable when everyone, everywhere uses '>' as a quote sign.  I've seen this convention broken many times with '|' as the most common substitute.  Using '> ' (or using kmail's escapes '>%_') is a direct violation of this assumption; when using it, the behavior of your mail client cannot be expected to exactly follow this RFC.

Finally, the RFC itself implies that your second rendering in the original report is most correct, rather than your preference (the third rendering).  Specifically look around lines 421-426 and 567-573.  The space immediately after quoting is called "stuffing" in the ABNF provided and there is a comment about stuffing in that ABNF to wit: "space-stuffed, added on generation if needed, deleted on reception".  Therefore, kmail should remove the space before rendering.  (And oddly enough, cannot add or remove it immediately before the signature separator, '--'.)  Though, see [3] below.

My recommendations (as a lowly user) would be:
1. Allowing a space as part of a quotesign (or between quotesigns) breaks the practice of space-stuffing and KMail should disallow it.  It is essentially impossible to tell where nested, differing, quote signs end if space is allowed.
2. Adding a space after the quotesign before sending is always acceptable.  It's standard space stuffing.  It's required when the line starts with a space (so that the other end doesn't remove the space under the assumption it was stuffing) or any mark that might be considered a quote sign.
3. Displaying a space after the quotesign(s) both during reading and composition is a nice feature and should be preserved even if storage and/or transmission of the space is not.  KMail is a rich email client so users will be comfortable with the "cooked" rendering.  Of course, 'View Source' ("raw" rendering) would display exactly what is stored -- and space stuffing should never be stored.
Comment 6 Boyd Stephen Smith Jr. 2009-01-07 23:58:09 UTC
Probably should be closed.  The only RFC that has to do with quoting doesn't apply when the user has set the quote-sign to ">%_".  That said, it would be nice if Kmail defaulted to RFC-conformant behavior and had the quote-sign set to ">".
Comment 7 Björn Ruberg 2009-12-21 21:22:11 UTC
Closing as suggested