[Doc-SIG] reStructuredText inline markup

[Tony J Ibbs (Tibs)]

Despite his saying he won't get involved, I like Ueli's analysis of
possible ways around your problem. I'd add that I think Alan is maybe
working to the wrong model - I think of reST as more like a simple text
formatting language, rather than more like a data description language.
Consider how one would derive (for instance) TeX code from it, and what
that would look like on the page.

Alan Jaffray said:
> The only comments I can find, searching on "nested inline doc-sig" or
> "nested inline restructuredtext", are David's remark of "that way lies
> madness" with no explanation and Tony's note that it'd be a pain to
> implement and he wasn't certain how important it was.

As David says, there's more history than that.

My failing memory (isn't it always) hints that ST has never supported
nested inline markup (or at least, not predictably) - that may have been
despite claims to the contrary. Don't know about setext.

My own "prototype" system was very simple, and was re based, and I was
leaving such stuff for later - whilst it is clearly *possible* to do
nested inline markup with simple re usage (you recognise one level,
split the text out and leave "markers" behind, then recognise the next
level, etc., taking care not to introduce ordering problems), it's a
pain (I knew broadly what to do, but the implementation would be that
sort of fun that isn't, if you see what I mean, and there were other
things to do).

Trying to get three people (e.g., me, Edward Loper and David) to agree
on what made *sense* in terms of nesting was difficult, too - what about
edge cases like ``*Emphasis enclosing **bold***``?

I'm sure David could write his parser to cope with nested inline markup,
but the nest of snakes isn't so much in the implementation as in the
description of what is allowed - it looked like it was always going to
introduce potential unexpectedness. The "solution" of dropping
**strong** emphasis was not acceptable, which leaves the other
"solution" of leaving it alone until a strong case for the need for it
is made, possibly with appropriate patches (to code *and*
documentation).

My initial reaction to that approach was one of dismay, but some intense
thought quickly showed me that, in practice, I could easily live with
the restriction, at least for the initial roll-out of reST and DPS.

"simple is better than complex"

Tibs
--
BikeCode0.2	http://www.tibsnjoan.co.uk/bikecode.html
  P: [Tibs] Tc B10 K:++ i29:30" h1.65m n1960 H+:~ v~ A+ M+ Rg-
  B: [AnthroTech]   3tRu U1c w37" Wr19:406 Mfr SAf bDh[Sachs]:C
                    G3x7 8s Lrr1B Cb[Michael] VjsX col[MidnightBlue]
  T: [BurleyD'Lite] 2c2[Thomas] f++ VsX
My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)