Re: [PATCH] fix indent_string handling with format=flowed
Hi,
* Johannes Stezenbach [07-10-14 21:54:36 +0200] wrote:
On Sat, Oct 13, 2007, Rocco Rutte wrote:
* Johannes Stezenbach [07-10-12 23:14:21 +0200] wrote:
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).
I must confess I'm a bit confused at the moment as to what the
desired behaviour is. So let's talk about this first.
At the moment, with $text_flowed set, replies to non-flowed mails
get ugly quoting with '>' instead of '> '. Mutt _displays_ such
quoting as '> ', but to people with other MUAs it might look bad.
Not really. If mutt did send that line out quoted as '> ', to other
clients it means that the line has been space-stuffed and that space is
to be removed to just '>' (read: it'll always look as '>' to other
clients except they add a space).
However, after removing such spaces, concatenating lines and rewrapping
them, mutt adds a space again for display purposes only so that it looks
nicer. I didn't check the archives, but IIRC there was some discussion
about it some time ago.
I think to correct this behaviour, the forcing of prefix='>' at the
start of _mutt_copy_message() must be removed. But I guess this
was done there and not in rfc3676.c because mutt tries to handle
quote levels in RFC 3676 way *even when replying to non-RFC 3676 mails*.
IMHO mutt just shouldn't do this, then to problem would go away.
I'm not really sure what you mean here. All that code does is set the
prefix for properly quoting lines. For $text_flowed=yes it always has to
be '>' (without space) since RfC 3676 requires that. Otherwise it's what
the user configured, though it's ignored when replying to a f=f mail
regardless whether $text_flowed is set or not (for interoperability with
f=f).
Or it should do it correctly, i.e. use '> ' for the first level
of quoting and '>' for further levels (which is a bit more work
to implement that just forcing a fixed prefix).
For the f=f handler or in what situation exactly? For both, 1) sending out
f=f messages with $text_flowed set and 2) replying to f=f messages this
breaks message handling on the receiver's side.
For 1), a line of a f=f message '> >>foo' has a quote level of 1 and the
line is '>>foo', not 3 and 'foo'. For 2), it again breaks
interoperability.
My initial problem is the contrary case, $text_flowed unset and
replies to flowed mails. My opinion here is that mutt should
honour $indent_string in this case. I think the reason it doesn't
is "improved interoperability with format=flowed users" when
they reply to the reply.
I do see your problem, but the subject is quite tricky. Again: if mutt
did use $indent_string, it would have to strip all trailing spaces in
addition to make sure that a f=f reply on that message still looks okay
(but since a replying user will generate f=f it'll still require him to
take some actions; e.g. when he gets quoting as '> >>foo', he'll have to
fix it to '>>>foo' first while making up a reply).
So I think we're again talking about a "downgrade format=flowed to
format=fixed" option, right?
Because in order to be abled to use $indent_string on f=f messages, mutt
(for interoperability) has to make sure no parts can be flowed later on
by f=f replies. As I wrote in the other mail, in that case no using the
f=f handler won't do it since the default text/plain handler leaves
spaces in.
However, as I explained before:
There's also a catch: If you're creating a format=flowed mail
as a reply to a format=fixed mail, then you cannot make any
assumptions about the text you are quoting. RFC 3676 doesn't spell
this out, but IMHO you must then delete all trailing spaces
from the quoted text to ensure that it will not be accidentally
be treated as flowed.
But that's the opposite case of your initial problem, no?
Well, I think we agree that in the end the fixed part must render
properly as part of the f=f message. I think it's up to the user to
ensure it while you think it's to mutt, correct?
Rocco