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

[Benja Fallenstein]

Hiya,

Beni Cherniavsky wrote:

>On 2002-12-19, Benja Fallenstein wrote:
>  
>
>>I've been idly pondering ReST email before, so I have my own ideas about
>>this :-)
>>
>>I don't think that parsing arbitrary incoming emails as ReST makes much
>>sense-- it'd be like running all .txt files on my harddisk through the
>>ReST tools. I wouldn't want to use this on any emails butthose
>>explicitly written as ReST.
>>
>>    
>>
>True.  But problems can arise with:
>
>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...
>

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?

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

(BTW, email is quite often edited when being quoted :) )

>Something like treating every paragraph that doesn't parse as literal
>would solve some of the issues.
>

This could potentially be done by the ReST Tidy tool... OTOH, aren't the 
paragraphs where you actually used some ReST-like markup most likely to 
contain 'sloppiness'?

>>The applications I envision are two flavors of email user agent (for
>>reading & writing email):
>>
>>    
>>
>*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.)

>>- A text-based client, which would provide tools for composing ReST
>>e-mails, most notably a syntax validator (so that you don't accidentally
>>send emails that cannot be read because they aren't ReST); this would
>>send emails as text/vnd.python.rst or so.
>>    
>>
>
>I want such a tool.  I feel more need for editing features than for
>validation (all right, one day there will be an emacs mode).  Of course it
>would reflow paragraphs instead of broken line folding :-).
>

Yup :-)

>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?)

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

Besides, I think text/vnd.python.rest is exactly how MIME types are 
supposed to work: Everybody who knows it treats it specially, everybody 
who doesn't sees it as plain text. That was the idea behind 
text/enriched and text/html-- except that SGML isn't very readable and 
people complained about the angle brackets in the e-mails they recieved...

>>The difficult question is how to do quoting; I think (contrary to what
>>some people seem to be saying here) that quoting should not generally be
>>done through literal blocks-- I think quoting of non-ReST mails should
>>be, but quoting of ReST mails should preserve the formatting of the
>>quoted mail.
>>    
>>
>
>Who argued that?  IIRC, all the discussion assumed that the quoted block
>can be literal or not depending on presence of ``::``, similarly to the
>way it currently behaves with indented blocks.
>

Ok, I probably misunderstood something. Sorry.

>>More to the point, the rules would be as follows:
>>
>>- A block where each line is prefixed by "> " (angle bracket + space) is
>>*quoted*.
>>- A block where all but the first line is quoted by "> " is *quoted with
>>source given*.
>>- If the first line in a "quoted with source given" block ends in a
>>double colon, this quoted block and all following quoted blocks
>>*without* source given would also be literal blocks.
>>- If the first line does not end in a double colon, this quoted block
>>and all following ones w/o source would just be quoted, not literal blocks.
>>- (If there's a quoted block w/o source, and there is no quoted block
>>with source above, that block would be just quoted, not literal.)
>>
>>    
>>
>I think I like this.
>  
>

:-)

- Benja