Version: 1.10.1 (using 4.1.2 (KDE 4.1.2), Kubuntu packages) Compiler: cc OS: Linux (x86_64) release 2.6.27-7-generic Turning the Wordwrap option off in kmail's composer does not stop it from wrapping lines when the message is sent. Up through KDE 3.5.10 this worked properly. In 4.1.2 it is a problem (not sure about 4.0.0 through 4.1.1). The bug rears its ugly head when I'm trying to send a 120 character URL and it is breaking it up into two lines. First, this is well below RFC 2822's maximum line length of 998 characters so this is not the issue. Secondly this behaviour is creating a barrier for computer users who are not very literate who either do not understand or have great difficulty cutting and pasting two lines back together to form a valid URL. Thank you, Bill
Created attachment 28451 [details] Example of HTML email with 326 characters on a line Howdy, Personally I do not like HTML email because of the large message size. I just sent an HTML email because I was able to send a link without it wordwrapping and breaking the link. So I looked at the email source and the longest line was 326 excluding the line feed! I've attached a copy so you can see. I modifed a few of the headers to remove email addresses. Why can't I send a non-HTML email with lines shorter than 998 if HTML emails generated by KMail are not restricted? Please fix this bug and allow non-HTML emails to be free from word wrapping on lines shorter than 998 characters. Thank you!
While kmail 1.10.90 (trunk svn r882080) is able to send and retrieve plain text mails with lines larger than 1000 characters (encoding the mail body in base64), the wordwrap option still does some strange things. With wordwrap enabled, if I paste a (half the composer window size without spaces) string, type space and paste again, the last pasted string is in the new line. OK. With wordwrap disabled, if I paste the string, type space and paste again, the last pasted string is in the same line, if I type space and paste again, the last pasted string is a new line. If I paste the string 10 times (without spaces), it is not wordwraped ever. If I change the composer window width (srinking it), the lines with spaces are reassigned as if wordwrap is enabled.
This bug is especially annoying when sending patches. If the patch has long lines, the composer window must be resized to be wide enough to prevent KMail from wordwrapping and thus corrupting the patch when sending. On a small screen you may need to make the composer window wider than the screen. Simply disabling wordwrapping from the Options menu isn't enough. The bug 238629 seems to be a duplicate of this bug. The bug 219572 might be related to this bug.
(In reply to comment #3) > This bug is especially annoying when sending patches. If the patch has long > lines, the composer window must be resized to be wide enough to prevent KMail > from wordwrapping and thus corrupting the patch when sending. Yes, exactly. And it's not just a problem when sending patches. The bottom line is that KMail should *NEVER* be inserting hard line breaks into messages unless word wrapping is enabled. If a line is wider than the composer window, it can soft-wrap in the composer window, but that is an issue of the *editor*, not the *document*. The size of my composer window should have absolutely no effect on the content of the message I ultimately send. And just to drive the point home, if I type a long paragraph of text that is greater than 1000 characters, KMail must throw out 7bit content transfer encoding as a possibility and use only quoted-printable or base64. It should *NOT* just throw in a hard line break wherever it wants to. Again, the *document* should be unchanged by whatever transfer encoding happens to be in use. For the record, the last version of KMail 1 that I used did all of this perfectly right. (In fact it was one of the few MUAs that actually did.)
I just tried to reproduce this bug with KMail 4.11.1, but it seems to be fixed now. What I could observe: - Long lines are softwrapped, no more hardwrapped. - This is also true when saving the email as a draft and reopening it. - Content-Transfer-Encoding was 7-Bit for long lines (less than 1000 characters), but quoted-printable for *very* long lines. Looks like it works perfectly now. Is anybody still hitting this bug?
Works perfectly for me now. I'd call this bug licked.
I guess the problem remains with urls with "-". For example, try to paste several times: http://code.google.com/p/address-sanitizer/wiki/AddressSanitizer It will be splittled by address- sanitizer. At least it does here to me.
Ups, sorry. Yes, it works, I had the wordwrap option (with a strange spanish traduction) on.
close based upon recent feedback.