Flowed text

[Peter Bloomfield <PeterBloomfield MindSpring com>]

RFC 2646 (http://www.imc.org/rfc2646 -- thank you, Brian, for the pointer!):

  proposes a new parameter to be used with Text/Plain, and,
  in the presence of this parameter, the use of trailing whitespace to
  indicate flowed lines.  This results in an encoding which appears as
  normal Text/Plain in older implementations, since it is in fact
  normal Text/Plain.

The idea is to avoid `embarrassing line wrap' of what is logically paragraph text. 
The definition of `text/plain' is extended to include a `format' parameter (or 
attribute), with values `flowed' (representing paragraph text) and `fixed' 
(corresponding to the current semantics of `text/plain', and assumed by 
default).

The attached patch (against today's cvs tree) represents a first cut at 
implementing RFC 2646 in Balsa. The core parsing and wrapping functions are in 
libbalsa/misc.c. Changes elsewhere, and there are many, are largely designed to 
keep the use of `format=flowed' optional, both in parsing incoming messages and in 
creating outgoing messages.

The benefit of `format=flowed' is that text entered as a paragraph, using the 
`Enter' key only to indicate paragraph breaks, is held in a form that allows it to be 
rewrapped, with or without quoting. Line breaks inserted to wrap a paragraph are 
`soft', indicated by a trailing space on the line; line breaks inserted when the 
user hits `Enter' are `hard', with any trailing spaces deleted. (However, if the 
user backs up and inserts a space at the end of a line, it isn't deleted, in this 
implementation; it could be, and arguably the RFC says that it SHOULD be, but that 
seems like unnecessary interference!)

The downside, of course, is that text entered other than from the keyboard, such as 
source code copied and pasted, may be incorrectly reflowed (another reason to 
avoid trailing whitespace!); this can be avoided by disabling recognition of 
`format=flowed'.

In principal, messages generated as `format=flowed' appear reasonable to a 
non-flowed-aware MUA, but this may break in practice; if it is a problem, 
generation of `format=flowed' messages can also be disabled.

One further limitation is that the reply prefix must be precisely ">". However, the 
RFC includes `space-stuffing', which is used in this implementation to insert a 
single space between the strings of '>'s and the text. This space has the dual role of 
visually separating the text from the quote string, and allowing a text line 
beginning with a '>' to be distinguished from a quoted. The user's quote regex 
should therefore probably be changed to "^>", to get the right quote-coloring; 
this implementation doesn't do that--some users may not want their regex changed 
without their permission!

`Reflow paragraph' and `Reflow message' seem irrelevant when generating flowed 
text, and are disabled.

The code works in minimal tests (this message, for instance, has 
`format=flowed'), but is presumably full of flaws. The wrapping code 
(dowrap_rfc2646) would look good only to a spaghetti lover. I'd be *most* grateful 
for feedback from testing, rewriting, corrections of my interpretation of RFC 
2646, and any other helpful activity!

Peter

rfc2646.patch.gz