On Fri, Dec 11, 2015 at 12:34:29PM -0800, Kevin J. McCarthy wrote: > On Thu, Dec 10, 2015 at 10:12:37PM -0800, Will Yardley wrote: > > On Thu, Dec 10, 2015 at 05:49:40PM -0800, Kevin J. McCarthy wrote: > > > What happens with unpatched mutt-1.5.23 if you unset reflow_text? > > > > However, if I'm understanding the description right, it seems like this > > should be ignored like $indent_string (or at least turned off when not > > explicitly set) if $text_flowed is unset > > It makes sense to ignore $indent_string when $text_flowed is set because > the indentation is set by the RFC. > > $reflow_text is used when displaying (and generating reply text), which > are somewhat independent from whether you want to generate flowed emails > or not.
The docs say: reflow_text Type: boolean Default: yes When set, Mutt will reformat paragraphs in text/plain parts marked format=flowed. If unset, Mutt will display paragraphs So based on that, I understood this to mean that $reflow_text and $reflow_wrap are specifically applied to text parts marked as format=flowed text only. Am I reading the man page wrong on this? The odd thing is that, while you say $reflow_text affects display, I see: >> foo in both the raw message (if I hit 'edit-message' to view the raw message in my editor), and in in the internal pager, but get: >>foo in my editor when replying to same (though my memory is that it used to show up as >>foo in the pager too). So I think the *display* issue was either fixed separately, or is controlled by a different setting. > > ... are there other conditions under which this setting would > > be useful? I would think that sending the reply through the > > rfc3676_handler when not generating flowed_text would be broken > > behavior. > It's certainly confusing! But I don't think it's broken. Reflowing > might make it easier when replying using fixed width (ignoring the > current quoting issue) by allowing you to control the width in the reply > yourself (via $reflow_wrap). Also, I think it gives us an opportunity > to "fix" the quoting, which you argue next: Yes, but in the case where the text isn't flowed, I think there's a better argument that one shouldn't monkey with the format=flowed text has a very strict interpretation of what's "quoted" or not (though obviously mailers that *generate* f=f may sometimes improperly determine what's quoted when quoting material generated using conventional quoting). In other words, f=f >>> foo means "foo" with 3 quoting levels, whereas with a text/plain message with the content: > > > foo we would typically assume the same. But we might also see super-cite style quotes (FOO>), or just literal leading ">"s. > On Thu, Dec 10, 2015 at 10:27:31PM -0800, Will Yardley wrote: > > ps - Given text known to be f=f, I'd also prefer to see the quoted > > section like: > > > > > Yay! > > > > > > > > Noes! > > > > vs. > > > > > >> Yay! > > which is more consistent (and, I think, what the $stuff_all_quoted may > > have done). Since with format=flowed text, lines starting with a '>' are > > quoted, and the depth is determined by the number of '>' characters, I'm > > not sure that the argument that you're reformatting the message in an > > unexpected way carries here [...] > I can understand this if we route through the text_plain_handler() - > there we have no business messing with content. But in rfc3676_handler, > as you say, the quotes are conceptual. If $text_flowed is unset, I > don't see why we couldn't allow for the quotes to be represented > differently. Yes! That's kind of what I was getting at, and yes, agree we should not mess with the former case. Since most mutt users are *not* generating format=flowed messages (and I still argue that, even with an editor that supports it, it's tricky to really do well in a mailer that doesn't have its own editor), I do think it's important to make things work optimally for this common use case (*replying* to f=f messages when not generating them). > A couple ideas come to mind. One might be a boolean setting that adds > spaces after each quote at each level. So ">>>Foo" turns into > "> > > Foo". Another idea would be a setting that specifies the desired > quote string yourself. So, to achieve the same result, you could set it > to "> ". It seems to me that it should just honor $indent_string, since that's already documented. Just, in the case of f=f text, there could be an additional option to *enforce* indent_string on the entire quoted section. w
