<<< Date Index >>>     <<< Thread Index >>>

Re: [PATCH] fix indent_string handling with format=flowed



Hi,

* Johannes Stezenbach [07-10-15 23:46:23 +0200] wrote:
On Mon, Oct 15, 2007, Rocco Rutte wrote:
* Johannes Stezenbach [07-10-14 21:54:36 +0200] wrote:

According to RFC 3676:

  Note that because of space-stuffing, the lines
      >> Exit, Stage Left
  and
      >>Exit, Stage Left
  are semantically identical; both have a quote-depth of two, and a
  content of "Exit, Stage Left".

Since the goal of RFC 3676 is to create messages which are as
compatible as possible with plain old MUAs, mutt should IMHO create
the ">> Exit" variant (i.e. the first level of quoting adds
'> ' and any further level just '>').

That would be nice, yes. When f=f-replying to a f=f message it's the case, when f=f-replying to a format=fixed mail this is tricky (code-wise). See below.

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).

In the context of what I wrote above this is not correct.
With $text_flowed=yes there are two cases:
1. reply to a format=flowed mail: to be handled by rfc3676.c,
  count quoting levels and add '>>> ' according to level

That's what the code does already.

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'.

Second, since the original mail is format=fixed, the default text/plain handler is used. And there I guess it'll be quite tricky to tell it to ensure a space between quotes and text because that would have to use $quote_regexp in some iteration to determine the end of quote. Again, using '> ' as the leftmost quote prefix is just wrong again as it'll produce lines like '> >>...' with wrong quoting according to RfC 3676.

Personally I'd categorize this as a display issue only since a message with no space still is fully technically correct 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).

This seems to be what Apple Mail is doing. Apple Mail does this
even when replying to format=fixed mails. Apple Mail also seems
to count quoting levels fuzzily, i.e. it converts '> > foo'
into '>>> foo' on reply. (Which IMHO is unnecessary but doesn't hurt.)
(A quick look at some mailing list inbox of mine shows Thunderbird does
this, too.)

I'm fine with using '> ' as the first and '>' for all other levels. But treating '>> foo' and '> > foo' the same is wrong.

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.

IMHO it doesn't break anything. I think the RFC 3676 quoting levels
are only meaningful wrt to reflowing quoted lines. But if a mail is
format=fixed you can't reflow it anyway (see below). The MUA is
still allowed to recognize '> >>foo' as three levels of quoting and
display it accordingly (just like $quote_regexp in mutt does).

Uhm, no. Quoting are levels are clearly defined by the RfC. Either mutt claims to support the standard and does what it can and what is reasonable to keep them or mutt doesn't.

If mutt creates a format=fixed mail with '> >>foo'-style quoting, it's okay; when it creates a format=flowed mail it's not if it used $indent_string='> '.

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.

I checked and this is indeed what Apple Mail does.

But you don't want mutt to do that, too?

At the bottom of this is:

- if you see a quoted line with a trailing space in a format=fixed
 mail, you seem to assume it must obviously come from a
 format=flowed mail thus you can treat it as such when creating
 a reply

- but I on the contrary think that this assumption is invalid and
 you must treat the line as fixed by removing the space when
 creating a reply

No. When a format=fixed mail has a trailing space then mutt assumes the line has a trailing space only because somebody put it there for a reason and leaves it alone. This sounds stupid, I know, but mutt really doesn't make the above assumption at all. Also, I'm confused by your conclusion from that false assumption.

I think I already wrote that: mutt doesn't distinct between handlers for reply and handlers for display. That means if you have a format=fixed message, mutt will always use the default text/plain handler independent from $text_flowed (that's why the prefix is managed externally in _mutt_copy_message()).

The space preservation is because mutt doesn't care at all about trailing spaces in the default text/plain handler since there's no point in it doing so; it does specifically not preserve them because $text_flowed is set. When you write a proper f=f message but don't set $text_flowed and reply to it in the same way, you have a format=fixed message with lots of trailing spaces. If you now edit the header and make it f=f, you'll get a rewflowed message.

I'm also confused by that second point since earlier (and in the other mail I'm ignoring to consolidate the discussion) you mentioned you don't want mutt to have a "downgrade" feature, which I "defined" to be exactly that space removal.

So, I'll try to summarize what your points are again to make sure we don't talk about different things.

1) When replying to f=f messages, you want to be abled to use $indent_string if $text_flowed is unset. 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.

2) When replying to a format=fixed mail with $text_flowed set you want mutt to ensure that there's a space between quoting prefix and text. E.g. '> foo' instead of '>foo', '>> foo' instead of '>>foo', etc.

Rocco