Re: [PATCH] fix indent_string handling with format=flowed
Hi,
* Johannes Stezenbach [07-10-14 21:12:59 +0200] wrote:
* Johannes Stezenbach [07-10-12 23:14:21 +0200] wrote:
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);
?
What I have in mind is an option to tell mutt to not use
the f=f handler to interpret the message. I guess I could
edit the Content-Type and delete "; format=flowed", but I would
prefer an option which I could toggle with a hotkey, so that
I could usually leave f=f handling enabled but quickly disable
it in those cases where it gets in the way.
The implementation of that option would just prevent the
"handler = rfc3676_handler;" assignment in mutt_body_handler(),
thus treating the mail as plaintext.
I think a good name for that option would be "handle_flowed"
or "decode_flowed", default "yes".
Well, that won't do it completely, I'm afraid. You said it's unexpected
behavior for you if you have $text_flowed unset and by replying still
generate a partly f=f-fit message.
But that's exactly what you'll do with this approach because the default
text/plain handler (which mutt will use when $handle_flowed=no) doesn't
care about trailing spaces at all. And there's no point in it doing so
since the f=f semantics are only to be handled by the f=f handler (as
far as possible, of course).
So I think what you want mutt to do with $handle_flowed=no is:
a) Strip trailing spaces of f=f messages
b) Treat even flowed lines as fixed lines, i.e. don't rewrap
Part b) is what I think you meant with not using the f=f handler at all,
part a) is what the above snippet would do.
But for interoperability, I still think it's bad to strip the spaces in
replies. Rfc3676 doesn't say anything about the trailing spaces in its
interoperability section, but for e.g. space stuffing it says that non
f=f aware clients simply won't care and send out the spaces as they were
received so that f=f is interoperable.
At least I want mutt to do the same thing for the trailing spaces. Given
you can turn off wrapping of f=f completely via b), things will look
okay on your side, so why still bother about the trailing spaces others
may benefit from?
An example why this is bad: I think AppleMail sends out f=f by default
with DelSp=yes using two trailing spaces at the end of lines. They
"abuse" the DelSp feature to break overly long lines (e.g. URLs) by
appending only one space to those lines so they're simply concatenated
without a space on f=f aware clients. You'll break that if you remove
the spaces what others then might find annoying. Some mutt users even
reported they're happy that with this new f=f handler they can view
these URLs concatenated...
Me, I never ever set $text_flowed. (Maybe I'll do in the future
on occasion now that I know how it works ;-)
I think I've quoted it here already: Some people consider f=f to mean
"format=flawed". :)
So in a way it will never really work all the time unless everybody
sends out properly generated f=f.
Rocco