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

[Beni Cherniavsky]

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

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

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.

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

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

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

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

> - A graphical client, which would render text/vnd.python.rst e-mails
> graphically, and allow for graphical composing of ReST e-mails, like
> Mozilla's HTML email composer.
>
> This would finally allow me to use hyperlinks, variable-width fonts,
> italics etc.pp. in composing & reading e-mail, without worrying about
> unreadable font size settings, people complaining about HTML mail bloat,
> people turning off HTML mail (like me :) ), or readability on text
> terminals; instead, I'd know that any email client would get something
> it can read, w/o bloat, and people with a graphical ReST mail reader
> would see themail the way I typed it (modulo preferences like font or
> text size).
>
> 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.

> Also I think that quoting should be done through the
> commonplace ">" syntax; this is simply the most wide-spread variant, and
> forcing something else down peoples' throats seems wrong. To
> disambiguify from doctest blocks, choosing the ">" + space syntax as
> required for ReSTmail seems good.
>
> To discriminate between literal and non-literal quotings, I'd suggest:
>
> I wrote:
>  > foo
>  > bar
>
> for non-literal quoting, and
>
> I wrote::
>  > foo
>  > bar
>
> for literal quoting.
>
> 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.

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