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

Re: [PATCH] to improve the rendering of format=flowed quoted text



 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,
> either--avoiding them hardly seems worth the added code complexity, as
> trivial as it may be.

    I disagree. That's for sure a little detail, but we have to care
about what numerous users will send for the numerous future years. I'm
perhaps over-picky about what Mutt sends, but I feel such details are
more important than other "local" things that may need polishing, but do
not reach the outside.


> As for the pipe symbol, it's just one of many "non-standard" quoting
> symbols.

    Yes I agree it's discussable, and I choosed to treat pipe and not
others mostly only because of my own habits. Also to be consistent with
a smart_quote feature I'm working on (for non-flowed case).


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

    IMHO *this* would be overly complicated. Especially that the users
will of course rush to configure something breaking 2646.

    In fact I proposed '|' as a middle between none special symbol and
more with full configurability and foolproofing.


> then logically we should treat any other quote symbol in the message
> content, such as '>', the same way, which would contradict RFC 2646.

    Of course I didn't propose that, because of the said contradiction.
But you missed the nice point that following 2646 does automatically
what we want: No stuff '>' when it's a quote symbol, stuff it when it's
a "greater than" symbol at the beginning of line's content.


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

    Me too.


> As for trying to preserve the intended indentation of tabs, I think
> that's outside the scope of this patch.

    Well yes. To be clear: 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.


Bye!    Alain.
-- 
« Be liberal in what you accept, and conservative in what you send. »
        Jon Postel / Robustness Principle / RFC 1122