Context dependent markup (was [Doc-SIG] Re: Ho hum - back to work...)

[Tony J Ibbs (Tibs)]

Edward D. Loper wrote (well, in response to me):
> > I still don't understand why Edward (and Guido, although I think
> > he's less likely to answer!) object to "simple" markup like ST and
> > relatives use - why they consider it a Bad Thing to (a) use
> > punctuation characters for markup, and (b) use them in a context
> > dependent manner.
>
> I actually don't object to either (a) or (b), strictly speaking.  What
> I object to is markup that I think will be "unsafe."  For example, I
> have no problem with using *one* *word* *emph*, or saying that
> backticks around any valid Python identifier mark it as a Python
> object.  My biggest pet peve about ST-like markup is having a markup
> be context-dependant, with a basically unbounded context.. For
> example, if "*" starts an emph region only if there's another "*"
> later in the string somewhere; and otherwise is an asterisk.

Which I don't think I've ever proposed...

> This
> seems very dangerous to me.  I want to be able to tell (under most
> circumstances), by looking at a character and its immediate context,
> whether it's markup or not..

But my problem is that I think this has always been possible (and I
think you disagree) so there is clearly some leeway on this clarity,
which is what I'm trying to track down.

> So, as long as we keep our contexts
> relatively small, I don't object to context-dependant markup.  (In
> fact, both bullets and "::" are definitely context-sensitive markup,
> and I think they're very intuitive.)
>
> As for using punctuation characters, that's fine (what else would you
> use??), but if possible we should try to keep the need for escaping to
> a minimum, because escaping will be ugly and non-intuitive, no matter
> how we do it.  So we should try to keep the number of punctuation
> characters we use to a minimum.

Ooh - there's that nasty POD-clone (hmm - bad puns about pod-people
narrowly averted)

> > (As a subpoint, I don't *quite* understand why Edward wants to
> > separate structuring and colourising so much - this seems to me to
> > be implementation detail (for this purpose, I consider the EBNF to
> > be "implementation" as well) - real people don't have trouble with
> > fuzzy distinctions about such things.)
>
> There are really 2 reasons:
>
>   1. A general divide-and-conquor approach to the problem of coming
>      up with a markup language.  I'm more confident that we'll be able
>      to come to consensus on smaller issues/domains than larger ones.
>      This reason has nothing to do with the final markup language, and
>      everything to do with how we get there.
>
>   2. A side-effect of dividing structuring and colorizing is
>      eliminating a number of issues, such as how to tell whether
>      a line in a paragraph starting with "1." is a bullet or a
>      continuation of the previous line.
>
>   3. I think that the markup language will be easier to understand
>      if colorizing and structuring don't interact much.
>
> My original reasons were (1) and (3).  (2) was something that happily
> fell out.

I like 1. I suspect that 3 doesn't always split *quite* that way, but
point taken. I think 2 addresses exactly that issue about how it doesn't
always split that way (and I tend to agree with Tim Peters' point some
while back that "if it looks like markup..." (to paraphrase
aggressively)). OK.

Tibs

--
Tony J Ibbs (Tibs)      http://www.tibsnjoan.co.uk/
"How fleeting are all human passions compared with the massive
continuity of ducks." - Dorothy L. Sayers, "Gaudy Night"
My views! Mine! Mine! (Unless Laser-Scan ask nicely to borrow them.)