"Andrea Pappacoda" <ta...@debian.org> writes:
As you can see, the Content-Type header has no Format parameter.
Yeah, (decoded) lines end with ' ' (ASCII space), but with no
Format parameter set to Flowed, they have no special meaning.
I stand corrected; I mistakenly interpreted f=f there. It seems
expectation bias played tricks on my mind. It seems that KMail (?)
has significant issues with f=f implementation.
F=F is a promising concept, but it can be surprisingly
challenging to implement correctly, even when it seems
trivial.
Is it? I wrote a simple flowed-to-html converter in something
like 50 lines of C. It may not be sophisticated, but to me it
seems to work as expected. As for composing, simple editors
like Vim can produce compliant text with a one-line
configuration option.
The specification is straightforward, yet many MUAs mishandle it,
particularly in edge cases. For example, Gnus exhibits numerous
peculiar bugs. In the last message by me you replied to, the final
paragraph fails to soft-wrap, unlike the preceding one, and Gnus
itself renders it as part of the same paragraph (unlike e.g.
Evolution). This indicates problems in both encoding and decoding.
I can only guess how this email will end up after I've sent it. I
really can't decide if I should use f=f or not.
Additionally, some messages contain sections that should never be
soft-wrapped, such as diffs. I'm uncertain whether many MUAs offer
a smooth user interface to designate which paragraphs should be
hard-wrapped. At least Gnus (message.el) does not.
