Re: [PATCH] to improve the rendering of format=flowed quoted text
Alain,
Just so you don't think I was ignoring you: We had a hiccup in our
mail delivery system yesterday and I didn't receive your message
until 7:25 a.m. PST--about 20 hours after you sent it. Thomas's
reply was delayed by only 3 hours(!), so I saw it yesterday.
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,
> > 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.
I didn't really see your point until I read your signature. I
hadn't thought about this issue in terms of being conservative in
what Mutt sends. Now that I have, I agree with you.
> > 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.
If '|' is just your personal preference for a quoting character,
then I think that it should not be hard-coded into Mutt. We should
either allow all users to specify their preferred quote character(s)
or dispense with it altogether. 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. Of course we would
have to address the problem of users specifying something that would
break Mutt's compliance with RFC 2646.
I think there are two issues here. The first is treating certain
"quoting" characters specially in the presentation of format=flowed
text. The second is the interaction between the formatting of
format=flowed text and your smart_quote feature. I can't really
comment on the latter since I don't know anything about the feature.
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. Of course, 1.5 is
the development branch, and if your feature is imminent, I/we could
just as well allow for it now as later. What do you think?
I would be a little more inclined to hard-code a special character
in the format=flowed handler if it was needed to support some other
Mutt feature that had hard-coded that special character. I think
it's generally bad practice to hard code such characters, but it
would be useful at least during development and evaluation of a new
feature, especially when on a development branch.
> > 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.
If you handle the user-specified character(s) it at the right point
in the code, you're right. Thanks for pointing that out.
> > 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.
Your "not stuffing tab addition" is part of your smart_quote
feature?
Regards,
Gary
--
Gary Johnson | Agilent Technologies
garyjohn@xxxxxxxxxxxxxxx | Wireless Division
http://www.spocom.com/users/gjohnson/mutt/ | Spokane, Washington, USA