[Doc-SIG] Alternative inline markup

[Tony J Ibbs (Tibs)]

Congrats to Alan on announcing RSTDocument - not something I'm likely to
use in the foreseeable future, but still a Good Thing!

Meanwhile, back at the discussion on reST itself...

Alan Jaffray wrote:
> Well, it's become clear that I need to provide much stronger
> arguments for why richer inline markup is important.  I feel
> pretty strongly that this is something that will come to bite
> us later, and not very much later, if we want rST to thrive
> as a general markup.  I have use for it now, and I have
> relatively simple applications and have barely started to
> use the language.

A feeling like that is very valuable, but, as you say, the rest of us
need articulation to understand the basis for it. Sufficient examples
will lead to either agreement, or "aha - but the way you do it is this",
or, at worst, a decision that the problem isn't going to be addressed,
but at least we understand why not. All of those are stronger positions
to be in.

> And yeah, it can be added later, but I *really* don't want
> to head down the road of writing reStructuredTextWithNesting
> while someone else writes reStructuredTextWithNestingDone
> SomewhatDifferent and someone else writing
> reStructuredTextWithChocolateSprinkles and the whole incompatible
> dialect-proliferation fiasco that STX has gotten itself into.

I hope that won't happen (judicial use of modes should prevent some of
it). But even with the best will in the world you can't stop it entirely
(in my paid field of work we have an example of a large company that was
involved in standards work, with one head, developing an incompatible
variant of the same standard with another head - if one head had talked
to the other, the standard would almost certainly have been extended in
the relevant manner (the requirements were real and sensible), but
unfortunately it didn't happen. You can't stop people from acting
without foresight.).

So, yes, it would be nice to solve it - but the case is still to be made
that we *have* to do it.

And I *do* think (from historical experience) that *deciding* how to
treat nested inline markup is difficult - I have generally had a very
laissez-faire attitude to the problem (so I would allow almost anything
that might make sense to someone, and expect the parser to cope),
whereas David and Edward Loper have had a much stronger wish to be able
to *describe* in a simple manner what is and is not allowed.

> Long email with more examples coming soon, I suppose.

Interesting times to come!

Tibs
--
Tony J Ibbs (Tibs)      http://www.tibsnjoan.co.uk/
"No one trike will do everything... buy the whole set!" - Rob Hague
My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)