Re: [PATCH] fix indent_string handling with format=flowed
Hi,
damn, this stuff is so subtle it's really hard for me to
find words to express myself without creating misunderstandings.
Maybe I should state my goals before we go into details:
- I want mutt to follow RFC 3676 by the book
(currently I think it doesn't)
- and I want a mode where I can disable all RFC 3676 processing
and have mutt behave like a plain old MUA
(this is for dealing with bad content created by other MUAs)
- I do not want any "downgrade" or similar function
On Mon, Oct 15, 2007, Rocco Rutte wrote:
> * Johannes Stezenbach [07-10-14 21:12:59 +0200] wrote:
>
>> 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.
By that I mean the forced '>' quote prefix. With $text_flowed=no mutt
should use '> ' or whatever I set as $indent_string. But note that
the text above does not deal with composing/replying, I deliberately
split this off into a separate mail.
> 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
No -- a plain old MUA wouldn't do this either.
> b) Treat even flowed lines as fixed lines, i.e. don't rewrap
Yes. Don't rewrap, don't un-space-stuff. Pretend it's format=fixed.
> 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?
Again: I don't want mutt to do anything to do about trailing spaces when
it composes a reply in format=fixed ($text_flowed=no). It either does
RFC 3676 processing (un-space-stuffing, paragraph reflowing) or
not (with my proposed $handle_flowed=no option). In both cases
trailing spaces will be preserved.
> 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...
What Apple Mail does here is contrary to the intent of RFC 3676
(to keep interoperability with plain old MUAs). RFC 3676
explicitly says that that "a generating agent SHOULD NOT
insert a space in an unnatural location" and "the agent SHOULD send
the word as is and exceed the 78-character limit on line length".
(DelSp=yes is not the problem, but breaking URLs is.)
But in other respects Apple Mail gets it right where mutt currently
does not. I'll explain more in the other sub thread.
Johannes