[Doc-SIG] formalizing StructuredText

[Edward D. Loper]

> I remember when most tools would show trailing whitespace visibly.

Fine by me, as long as we explicitly say that all spaces in text
(not in literals) are soft.  It seems like the parser *should*
reduce sequences of multiple spaces, but I'll live if it doesn't
(c.f., XML parsers are required to reduce sequences of multiple
spaces in attribute strings like this: '<x y="a   b   c">').

> Word wrapping is a presentation issue - if the renderer is generating
> etext, or STNG, then it may make sense to *not* word wrap.

Yes, but the reader should understand that their text *can* get
word-wrapped at (non-literal) spaces.

> > (unless, of course, you can give me a good reason why we *should*
> > preserve sequences of spaces.
> 
> No. It's only laziness. 

Ok.  Well, I'll be happier if parsers strip that whitespace eventually..
But I won't worry about it for now. :)

[Tibs discusses ***]

Ok.  So, on further thought, *** can be given consistant meaning
(assuming a left-to-right-style parsing):

CURRENT CONDITION |       Meaning
 Emph? | Strong?  |
-------+----------+-------------------
  no   |    no    | start both strong & emph
  no   |    yes   | end strong, start emph
  yes  |    no    | end emph, start strong
  yes  |    yes   | end both strong & emph

If you do give '***', that is the meaning it should recieve.  Note
that '****' shouldn't ever really have a meaning.

I guess I'll just have to wait for your nested-coloring regexps. :)
(But I still think that '***' is potentially confusing to readers,
and that's a Bad Thing).

-Edward