Re: [PATCH] fix indent_string handling with format=flowed
Hi,
* Johannes Stezenbach [07-10-12 23:14:21 +0200] wrote:
On Thu, Oct 11, 2007, Rocco Rutte wrote:
Mutt currently tries to keep interoperability by assuming that non-f=f
aware clients (including mutt itself with $text_flowed unset) treat f=f
mails just like any other mail and leave the spaces alone. As a result,
non-f=f users won't notice the difference at all while f=f users still
benefit from all f=f mails in a thread.
Mutt currently does more than that: Even with $text_flowed=no it
creates replies which are fit for $text_flowed=yes (forced
$indent_string=">"). In itself this isn't _wrong_, but is different
from what a non-f=f aware MUA would do, and from my perspective
it is undesired behaviour.
Contrary to the above, strictly speaking mutt isn't a non-f=f aware
client. With $text_flowed unset it well recognizes f=f, it just doesn't
attempt to declare it.
Furthermore, trailing spaces are only important since f=f came up, so I
guess that most MUAs simply don't care about them if they don't know
about f=f. Though I can imagine some simply remove trailing spaces for
no particular technical reason...
I still think that my patch does the right thing.
I think I see a problem with it. It removes the space between quotes and
text in the second hunk. I guess you're doing this because with
$indent_string defaulting to '> ' you'll end up with 2 spaces. However,
with $text_flowed set, s->prefix is only '>' so you'll remove that space
for f=f users, too making lines render as '>>>foo' instead of '>>> foo'
(which some earlier commit to rfc3676.c fixed).
BTW, in addition to "respect $indent_string with $text_flowed=no",
I think it would be useful to have a config option to disable
RFC 3676 handling of received messages altogether and make mutt
behave like a plain old non-f=f aware MUA.
Mutt with $text_flowed unset ignores the spaces and leaves them in. When
such an option was added and the standard text/plain handler be used
instead of the f=f handler, you'd still have the same problem: the
message interpreted as f=f would lead to some flowable paragraphs.
That would mean mutt doesn't need an option to disable f=f handling but
to "downgrade" f=f to format=fixed by removing all trailing spaces?
Mutt internally doesn't clearly distinct between rendering for display
and rendering for a reply but it just passes around flags. So a
downgrade still would have to use the f=f handler with omitting the
spaces. Lines 136/137 would have to be changed to something like:
if (pos + line < len &&
!option(OPTTEXTFLOWED) && option(DOWNGRADEFLOWED))
state_putc (' ', s);
?
That would be especially
useful in those cases where people send patches inlined in
f=f messages, where the patch is actually OK but displayed wrapped.
It may not be as clear as it should in the manual, but setting
$text_flowed is a really bad idea when sending out formatted content
like patches. And it's up to the user to take special care then using
$text_flowed.
Just as I write this I notice another thing which might be a bug:
According to RFC 3676 "4.1. Interpreting Format=Flowed":
A series of one or more flowed lines followed by one fixed line is
considered a paragraph, and MAY be flowed (wrapped and unwrapped)
as appropriate on display and in the construction of new messages
(see Section 4.5).
I think this means that a series of fixed lines should not be wrapped.
That works here (the text of yours I quote are series of fixed lines and
are not wrapped). Do you have any example?
Rocco