Re: [PATCH] to improve the rendering of format=flowed quoted text
On Monday, January 12, 2004 at 4:20:01 PM -0800, Gary Johnson wrote:
> On 2004-01-11, Alain Bench <veronatif@xxxxxxx> wrote:
>> On Thursday, January 1, 2004 at 7:28:56 PM -0800, Gary Johnson wrote:
>>> I don't see any problem with adding spaces to empty lines
>> I disagree.
> I didn't really see your point until I read your signature.
:-) So we'll thank Cédric Duval for his excellent
patch-1.4.cd.signatures_menu.2.1
[external quote char]
> If '|' is just your personal preference for a quoting character, then
> I think that it should not be hard-coded into Mutt.
OK: Midle choice rejected.
> Allowing users to specify this character is indeed a lot more work
> than hard-coding one character, but I think it is the "right" design
> choice.
Perhaps, yes. But more code, and yet another $variable, for a so
minor feature... We'll for sure hear the "oybng" word. Better no
external quote char special treatment at all than hearing the said word.
| $ echo $word | gpg --decrypt --cipher-algo ROT13
| reject
> The second [issue] is the interaction between the formatting of
> format=flowed text and your smart_quote feature.
I believe the only case of potentially bad interaction is while
replying to a format=flowed mail while in $text_flowed=no mode. True
there are yet unsolved problems (in fact this part of smart_quote is not
completed), but not related to the choice of special quote chars, be it
in stuff_all_quoted or in smart_quote. AFAICS so far.
I checked other cases and don't think there can be other problems.
At least, I'm *sure* smart_quote will never produce wrong 2646.
I meant this was more a matter of behaviour consistency. Otherwise
your stuff_all_quoted and my smart_quote are pretty much complementary,
giving the same look, but in different cases.
> I don't know anything about the feature.
Near to smart_quote in Slrn, or "compressed indentation" in
OE-QuoteFix. My present mail is written with it. Looks like flowed, but
is not.
> I would like to propose that any special handling of the '|' character
> in format=flowed messages be deferred until, or included with, the
> release of your smart_quote feature.
OK.
> if your feature is imminent
Sorry no. I'm slow, have not enough time, and it's low priority.
It's not half done, even if yet usable in a limited way.
>> Preserving tab indentation is not in scope of your patch because, as
>> with stock Mutt, it's naturally preserved. It becomes necessary only
>> because of my not stuffing tab addition.
> Your "not stuffing tab addition" is part of your smart_quote feature?
Here I was talking about my "&& *cont != '\t'" proposed addition to
your stuff_all_quoted. But yes, smart_quote also deals with that (for
cases outside of 2646).
Bye! Alain.
--
Software should be written to deal with every conceivable error
RFC 1122 / Robustness Principle