[PATCH] Re: format=flowed woes in signature handling

[Peter Bloomfield <PeterBloomfield MindSpring com>]

On 2001.12.13 15:28 Nuno Monteiro wrote:
> Hi,
> 
> Mostly in a follow up to message 
> <20011212200836.O15212@camera.vcsweb.com> by Gaelyne Gasson, where he 
> says:
> 
> [quote]
> "My only current curiousity is that something is mangling my 
> butterfly - the X and O in the center line up in my signature file 
> and appears correctly when composing mail  but when I view any mail 
> I've sent these are no longer lined up."
> [/quote]
> 
> I think I may have some insight on this, as this has happened to me 
> as well. This bug appeared somewhere around version 1.2.1 or so, and 
> has been there ever since. I noticed it a long time ago, but never 
> actually got around to reporting it, sorry. So, cutting to the chase, 
> it goes like this: I have the logo of the ASCII ribbon campaign in my 
> .sig file, and it puzzled me somewhat that the first line that 
> actually contained characters had an extra white space prepended to 
> it. That reminded me of another bug that existed in most 1.1.x 
> versions, where Balsa would _trim_ the whitespace from the beggining 
> of the first line of the signature. I reported that in June, and it 
> was eventually fixed in version 1.1.6. So, anyways, this case is 
> quite different, Balsa is failling to handle white space on a line by 
> itself, or whitespace in _the end_ of a line. Let me explain: I have 
> the "Signature separator" checked off, and I have two empty lines in 
> the beggining of my .sig file, before the signature text itself. Only 
> today, after toying around a bit with the signature I noticed that 
> the second of those two lines actually contained a single white 
> space, instead of being empty (eg, instead of containing just a 
> carriage return). So, I guess that Balsa is failing to handle that 
> case and concatenates the two lines together, and thats why I end up 
> having that trailing white space. If _any_ line happens to contain a 
> white space as the last character, that line will be prepended to the 
> next one. This is easily reproduceable, just do:
> 
> nuno:~$ echo -e 'foobar \nfoobar2 \nfoobar3 \nfoobar4' > .signature
> 
> Now compose a new message, and either postpone it or choose 'wrap 
> body', and all the foobars will appear in one line. And now, for 
> something completely different:
> 
> nuno:~$ echo -e '\n \n/~\\\n\\ /\n X\n/ \\\n' > .signature
> 
> Now, compose a new message. Choose 'Wrap body' from Edit menu, and 
> mind the gap (cool, this is starting to sound like the subway in 
> London) in the first line, mangling the ribbon. Thats because of the 
> single white space in the second line.

That's a feature of `format=flowed' (seriously, not a bug!). Lines that 
end with a space are treated as part of a paragraph that continues into 
the next line, and the new-line is ignored (RFC 2646). With the 
text-entry widget that Balsa's using right now, it's not possible to 
detect that the text was included from a file and maybe should be 
treated specially, so the line with the trailing space gets prepended 
to the following line.

Bottom line: trim the trailing spaces from any file you include, such 
as .signature!

> So far, so good. The message will look like this when I send it 
> (well, alledgedly), right? Wrong! Now, the fun part, postpone the 
> message, go to the draftbox and choose to continue. Behold. Uh-oh, 
> something broke.
> 
> (wrap body)
>  /~\
> \ /
>  X
> / \
> 
> 
> (postpone + continue)
>   /~\
> \ /
>   X
> / \
> 
> None of this happens if I uncheck Settings -> Preferences -> Mail 
> options -> 'Reflow messages of type text/plain; format=flowed', 
> though.

Now that's a bug, not a feature! A patch is attached that fixes this 
problem, and as far as I can see, doesn't break anything else.

Thanks for the report! 
Peter
diff -u -r1.328 sendmsg-window.c
--- src/sendmsg-window.c	2001/11/25 22:42:13	1.328
+++ src/sendmsg-window.c	2001/12/13 22:27:11
@@ -1693,9 +1693,12 @@
 	if (body && !body->filename) {
 	    GString *rbdy;
 	    gchar *body_type = libbalsa_message_body_get_content_type(body);
+            gint llen = -1;
 
+            if (msg->flow && libbalsa_flowed_rfc2646(body))
+                llen = balsa_app.wraplength;
 	    if (!strcmp(body_type, "text/plain") &&
-		(rbdy = process_mime_part(message, body, NULL, -1, FALSE,
+		(rbdy = process_mime_part(message, body, NULL, llen, FALSE,
                                           msg->flow))) {
 		gtk_text_insert(GTK_TEXT(msg->text), NULL, NULL, NULL, 
 				rbdy->str, rbdy->len);