Re: [PATCH] to improve the rendering of format=flowed quoted text
On 2004-01-01, Alain Bench <veronatif@xxxxxxx> wrote:
> Hello Gary, and happy new year to you all!
Hello and Happy New Year!
> On Monday, December 29, 2003 at 10:12:30 PM -0800, Gary Johnson wrote:
>
> > Attached is a patch for mutt-1.4i to improve the rendering of
> > format=flowed quoted text by space-stuffing all quoted lines.
>
> Thanks, small and very nice. It changed my mind about flowed format
> (I considered evil so far).
Thank you.
> May I suggest adding a little sophistication, so spaces are not
> added in situations where they have no visual nor functional effect (as
> empty or TAB-beginning lines), and before the external quote pipe
> symbol? AFAICS it's 2646-compliant. Like adding to conditions:
>
> && *cont && *cont != '|' && (*cont != '\t' || level % 8 == 7)
>
> The level calculation is for cases where "<Space><Tab>" and "<Tab>"
> are different visually, to preserve identation with other non-TAB lines
> at same quote level. Suggested *.2 attached.
On the one hand, I agree that there's no reason to add spaces to
empty lines. On the other hand, I don't see any problem with adding
spaces to empty lines, either--avoiding them hardly seems worth the
added code complexity, as trivial as it may be.
As for the pipe symbol, it's just one of many "non-standard" quoting
symbols. If we're going to treat the pipe symbol specially, then it
seems to me that we ought to allow other quoting symbols to be used,
and specified by the user, as the 'quote_regexp' does.
Then there is the issue of how mutt should handle quoting symbols in
the message content. RFC 2646 specifies that '>' used for quoting
are to be treated differently from those that being a line's
content. RFC 2646 requires lines whose content begin with '>' to be
space-stuffed. If we treat '|' like a quote symbol and don't
space-stuff it, then logically we should treat any other quote
symbol in the message content, such as '>', the same way, which
would contradict RFC 2646.
RFC 2646 doesn't specify how quoted text is to be displayed, so we
could handle format=flowed text differently when displayed than when
included in a message, but I rather like the consistency and
simplicity of handling them both the same.
I think it is cleaner to space-stuff all lines than to try to be
clever about recognizing non-RFC-2646 forms of quoting. While the
displayed text may look better when the other quoting is properly
recognized, there are no hard-and-fast rules for e-mail quoting, and
the message is apt to look worse if quoting symbols are incorrectly
interpreted.
As for trying to preserve the intended indentation of tabs, I think
that's outside the scope of this patch.
> > This behavior is controlled by a new boolean option,
> > 'stuff_all_quoted'. When unset (the default), mutt's behavior is the
> > same as without the patch.
>
> Is an option really necessary? I mean: Given the choice, would a
> significant amount of users choose the ugly unreadable old behaviour?
> It's a real question: I don't know the answer. I only know that me, as a
> user, I'd definitely choose permanently the new one and would just try
> to forget the dark ages.
I don't know, either. I thought there might be some who prefer the
existing behavior. Having the option also allows one to compare the
two behaviors. This could be useful while people are evaluating the
patch. I was also concerned that I might have broken something and
wanted to be able to easily remove its effects. In the long term, I
think it would be preferable to do without the option.
> The $stuff_all_quoted option name is perfectly clear for anyone
> familiar with the code and the RFC 2646. But seems to me a little
> confusing and cryptic for users. No suggestions, but $flowed_quote_space
> or $flowed_airing or something like that. Needs to be a more "visible
> feature" oriented name than internal variables.
If we keep the option, I don't really care what we call it. I
figured that 'stuff_all_quoted' at least stood a chance of being
understood by those familiar with RFC 2646. The issue is just
complicated enough that I don't think there is any short phrase that
can describe this option to less RFC-aware users. I guess that's
another argument for not making it an option.
Thanks for looking at this and for your suggestions. I'd like to
make this something acceptable enough to be included in the main
code.
Regards,
Gary
--
Gary Johnson | Agilent Technologies
garyjohn@xxxxxxxxxxxxxxx | Wireless Division
http://www.spocom.com/users/gjohnson/mutt/ | Spokane, Washington, USA