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

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