[Doc-SIG] Email Reader (was Re: reST block quotes)

[Beni Cherniavsky]

On 2002-12-19, Benja Fallenstein wrote:

>
> Hiya,
>
> Beni Cherniavsky wrote:
>
> >1. A thread where some people write rST and some don't.The quoted
> > illegal parts can easily spoil the rST context for the rest.  Literal
> > quoting for non-rST parts doesn't solve this entirely because the rST
> > messages quoted by the non rST parts lose their rST information...
> >
[Ooops, pine's quoting of indented text is broken.  Sorry :-]

> Yes, but somehow I'm inclined to think that wouldn't be all that bad...
> my feeling is that trying to guess the quoted ReST from a non-ReST mail
> is simply to hard and error-prone to be worthwhile...
>
> >2. Sloppy mail.I don't see myself writing 100% correct rST all the time
> > and I don't want it pushed down my throat.  If that's the choice, I'd
> > be more happy with writing rST as I see fit and using only the eyeball
> > reader ;-).
> >
> Hmmmmm... I can sympathize, but I'm not sure how to deal with it. I have
> a dislike for guesswork on the part of the parser... Maybe what's needed
> is a 'ReST Tidy' (like w3c's HTML Tidy): A program taking sloppy ReST
> input and trying to make it into real ReST. -- Could this run on the
> sender's computer, so that they can see what the output'll look like?
>
+1 on rST Tidy.

> >3. Once mail is sent, it generally can't be edited (since it's already
> > archived and people already hav it in their mailboxes).  I'm not sure
> > if anything can be done about it but it's a pecularity of email that
> > should be remembered.
> >
> What's the issue here?
>
Just that if after a broken rST is emitted, it's generally too late to
tidy it :-).  Thinking of it again, I see your validate-when-sending point
of view.  I agree - I would usually want to validate to avoid
inconveninece for readers.

> (BTW, email is quite often edited when being quoted :) )
>
But you can't fix the master which get's quoted afresh in new braches of
the thread...

> >*Breakage ahead*: your list is broken by line folding.Unexpected line
> >folding in the places where you least want it is all too popular with
> >email tool writers ;-(.Good rST that you write will end up broken for
> >some readers sooner or later.The "lazy indentation" ideas from the to-do
> >list could help here a bit.
> >
> Yes, but so is 'text/plain; format=flowed' [RFC2646]. It gets around the
> problem by requiring (IIRC) that compliant user agents shall not fold
> lines, but reflow instead-- ReST mail could do that too. (Mozilla
> supports it. It seems to work in most cases, and the remaining ones can
> be glossed over.)
>
Wouldn't it break every single literal block containg Python code, too?

> >I'm not sure I like text/vnd.python.rst.I don't want another text/html.
> >Most mail readers will probably complain that they don't know how to read
> >it.
> >
>
> Hmm. I wouldn't suspect this, but I haven't tried. (The reason I would
> suspect it should work is that the RFCs say very clearly that you have
> to treat it as text/plain, and that's not so hard to implement. But of
> course we know how good standards compliance is in most systems... Does
> anybody have experience in how mail readers treat unknown text/* formats?)
>
OK, you've obviously read more RFCs than I.  Glad to know it should work.

> >Sending identical content both as plain text and rST is more stupid
> >than sending text version of html mail :).I think it should be marked as
> >plain text and be autodetected simply by validating.
> >
> Don't like it. ReST is *not* plain text to my mind. I don't ".. note::"
> things in plain text...
>
I was only suggesting that because I didn't know any text/... should work.

-- 
Beni Cherniavsky <cben@tx.technion.ac.il>