[Doc-SIG] reST block quotes

[Beni Cherniavsky]

On 2002-12-16, Beni Cherniavsky wrote:

> On 2002-12-15, fantasai wrote:
>
> > Beni Cherniavsky wrote:
>
> > Requiring at least one space before the quote character
> > might not be a bad idea. It improves readability IMO.
> >
> But most mailers don't doit and manually converting is a huge pain.
>
> >> Also the "On Someday, Random Writer wrote:" is probably an
> >> attribution too.
> >
> > It is, but it's not practical to parse that since
> > people use so many different formats. It would have
> > to be treated as a paragraph, which really isn't
> > that bad.
> >
> Agreed.
>
The more I think about an email reader the harder it looks.  There are two
possible goals:

- Provide a slightly modified rST syntax that would making writing rST
  in emails more convenient (and maybe other goodies like processing the
  headers).  This is surely a goal.

- Simplify as much as possible convertions of mail written by rST-unaware
  people, or people writing half-rST mails (I do, especially when mailing
  without relation to Python).  This goal is very desired but can conflict
  with the first goal.

First, what's inconvenient with writing rST in email as it is now?
Nothing critical (except the quoting) but there are little issues here and
there.

One that I constantly experience is that indenting things in Pine is so
inconvenient.  True, I should switch to an external editor but I probably
prefer to accumulate the pain until it'll itch enough to write my own with
proper rST support (either an emacs mode or something standalone).  Don't
hold your breath.

I do think that some indentation demands could be relaxed, in particular
literal blocks should be allowed in column 0 (i.e. even with negative
indent!).  That would simplify cut-and-paste, in and out of the mail (e.g.
literal Pythom code can't be easily pasted into the interpreter prompt if
indented; doctest style is even worse).

The second goal opens a can of worms -- free text is too free to parse
automatically and needs corrections.  A good rST editor could ease the
editing but another possible approach is allowing many modes in the
reader, so you mark a whole message accrding to the style it's written in.
In the long run this is only useful if a normaling rST->rST convertion is
implemented...

BTW, maybe a generic syntax diagram parser [generator] would be useful to
rapidly experiment with rST syntax variations.  Getting automatic
"indent/reduce conflict" reporting would be very cool :-).

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