Re: [PATCH] fix indent_string handling with format=flowed
Hi,
* Johannes Stezenbach [07-10-16 14:54:05 +0200] wrote:
On Tue, Oct 16, 2007, Rocco Rutte wrote:
* Johannes Stezenbach [07-10-15 23:46:23 +0200] wrote:
2. reply to a format=fixed mail: just add '> ', not '>'
(sub optimal but IMHO correct according to RFC 3676 -- since
the lines are fixed they cannot be reflowed anyway and it
doesn't really matter if it is '>> foo' or '> > foo', and
the latter will look better in plain old MUAs)
First, as $text_flowed ist set, '> > foo'-style quoting is wrong while '>>
foo' is okay. It doesn't really matter whether the line is fixed or not,
it's a line of a f=f message with a quotelevel of 2, hence either '>>foo'
or '>> foo'.
I beg to differ: The quote depth as defined in RFC 3676 has only
significance wrt to reformatting of quoted lines. If a quoted line is
as fixed line (or a series of fixed lines, i.e. not a paragraph in
as defined by RFC 3676), then it is totally irrelevant if it is
'>> foo' ('foo' with a quote depth of two) of '> > foo' ('> foo'
with a quote depth of one). The quote depth just has no meaning
for fixed lines.
Only regarding flowing: yes. For all other aspects: no.
In a f=f message some f=f aware client has to determine the quote level
before even looking at whether the line is fixed or flowed, including
logical deletion of these quote levels (still before even knowing the
line is fixed). E.g. when you have a client that can hide and show
individual quoting levels, it won't recognize three fixed lines '>>
Foo', '> > Foo' and '>> Foo' as all being quote level 2.
Also, quote level detection is important for properly coloring quote
levels which mutt strictly speaking gets wrong, IMHO (for f=f).
RFC 3676 does not say anything that would prevent you from
recognizing '> > foo' in fixed content as a second level quote
and treating it as such in display.
And indeed mutt already gets this right, as do Apple Mail and
Thunderbird.
Oh, this is by actually accident. For f=f, it gets it right for coloring
according to $quote_regexp but not to my strict interpretation of
RfC3676-style quoting... But since this is display only I can personally
well live with it.
I think we disagree in our understanding of RFC 3676 in this point,
but if you read RFC 3676 again with the question "_why_ do they
define quote depth" in mind, then you'll see.
I already did that and I do agree that quote depths make most sense with
flowing. However, you have to admit that the quote level definition is
totally independent from flowed and fixed lines. To me this means that
there's only one technically valid quoting style.
That other quoting styles possibly don't hurt mutt/other MUAs or match
the interpretation of other MUAs is a different story. RfC 3676 defines
just this one quoting style and I'd like to see mutt doing the same
unless really everybody else does it differently for some time so that
it's become defacto standard.
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.
I checked and this is indeed what Apple Mail does.
But you don't want mutt to do that, too?
Yes, I do. I think Apple Mail gets this one right and mutt wrong.
(Thunderbird 2.0 also gets it wrong.)
Text from a format=fixed message is fixed and must be
quoted as fixed text in a format=flowed reply.
This is my understanding of RFC 3676.
I guess we could endlessly debate what "user-inserted hard line breaks"
are where agents should trim spaces, whether the authors really had
MUAs with external editors in mind (that usually don't know anything
about f=f and mail) and whether things one quotes count as such hard
line breaks, too.
I think what this means is not related to quoting but to text the user
enters. When he hits return, all trailing spaces of that very line are
to be removed since return means entering a fixed line. But I could be
wrong, though.
My main concern is still that in a discussion you'll loose all f=f
benefits if there's only one person doing a format=fixed reply that
turns all flowed into fixed lines. For example, in this discussion
between us you would have made messages harder to read for me if you did
trim spaces though nothing changes for you at all. Why would you want do
that?
I'd rather leave it up to the user to ensure he sends out only valid
f=f.
For example, my first mail in this thread contained a patch,
and patches always have some lines ending with a space.
If you had quoted this patch in your format=flowed reply with
current mutt, the patch would have been mangled on my display.
...and it would have been my fault, not yours or your agent's.
1) When replying to f=f messages, you want to be abled to use
$indent_string if $text_flowed is unset.
Yes.
This is where I think space
removal could be relevant for, but as said it's unclear to me if you really
want that and if so when exactly.
When creating format=fixed messages there are no spaces to be removed.
In this thread we have:
you) fixed
me) flowed
you) fixed
me) flowed
...
So that means when I reply to one of your mails my mutt should trim
spaces my mutt earlier send out because the former f=f parts were
declared fixed by your mutt... and fixed parts should not have spaces.
So, when my mutt makes that assumption why doesn't yours in the first
place?
I still think your mutt leaves them in because they don't do harm to
it. And I decide that they don't do harm either and leave them in when
making my f=f reply. If I find offending lines that could do harm it's
IMHO my job to remove them providing interoperability between flowed and
fixed messages.
BTW, I meanwhile realized that my patch was much too simple minded
and my claim that it "does the right thing" was wrong. I think the
required changes to mutt are somewhat larger.
Yes. I didn't really think about what exactly needs to be changed, but
it's quite a lot... and all probably outside the f=f handler.
For the other problems, I think we're slowly reaching the roots of our
disagreement, i.e. we need a referee and/or other opinions... :)
Rocco