> Earlier: "... Whether or not you think it's
> a waste of time, there's no excuse for
> broadcasting every parser bug you find
> to three mailing lists. There's no
> shortage of parser bugs, and no need
> to act surprised when you find one ...
> If we want to talk about the parser
> grammar effort, we all know which list
> to subscribe to ...
Peter Blaise responds: Oh? Which one? I do not know, and you do not
mention it in your post, so, help me out here, please - which list? If
you're gonna type something, why not make it unambiguously accurate and
complete, anyway? Otherwise, what's the point?
Additionally, I personally find cross posting very important. Of course
anyone NOT interested can just scroll on or delete - there's no such
thing as too much information in my book (on topic - I'm not talking
about spam or off topic posts). Parser behavior = wiki tech in my book.
I very often I find spirited discussions ensue because of cross-posted
ideas - it tends to freshen otherwise stale meeting places.
More to the point here, wiki markup parser wise, my point is twofold:
One, I would prefer NOT to have my wiki end users get error messages
when they edit. I'd prefer that any editing just go in and be saved,
and later we'll deal with formatting surprises. I'm a firm believer in
separating the tasks of content creation and content presentation.
Someone adding content to a wiki should never be delayed by presentation
formatting error messages. Let the text land however it lands, clean it
up later.
Two, we tend to discover how things work in spite of erroneous,
presumptive, naive instructions. I already have begun to discard the
"rule" that bold happened between three apostrophes. Instead, I've
discovered a hierarchy of toggles. Three apostrophes toggle bold to the
other state. Two apostrophes toggle italics to the other state. The
parser makes it decisions on how to interpret duplicate punctuation at
the END of any code that matches it's look-up-table, or at the first
"word barrier" transition. Or does it? Cut and paste this into any
sandbox page and explore:
'1text = apostrophe one text; no duplicate punctuation, no wiki markup.
''2text = italics two text; duplicate punctuation matched wiki markup,
and the parser toggles the state of the matching function, here,
italics.
'''3text = bold three text; duplicate punctuation matched wiki markup,
and the parser toggles the state of the matching function, here, bold.
''''4text = bold apostrophe four text; duplicate punctuation matched
wiki markup, and the parser toggles the state of the matching function,
here, bold (3 apostrophes) was the superior interpretable state before
the 4th apostrophe, so bold toggles (on or off), and the final
apostrophe is interpreted as mere punctuation or text. Alternatively,
four apostrophes could be considered as two toggles of the italics
function. But, since the first word barrier occurs only after the 4th
apostrophe, and there is no text between the apostrophes, that
interpretation would not have any visible effect on the display. It
probably makes sense to have the parser continue interpreting up to the
third apostrophe before making a decision, and consider it a call for a
bold-toggle, rather than consider the first two apostrophes as an
italics-toggle, and then start looking for a subsequent wiki markup
instruction. Otherwise, the parser would never find bold (3
apostrophes) if it always gave precedent to interpreting the first 2
apostrophes as italics. The parser seems to reads left to right, and
interprets according to (what we hope are ) discoverable hierarchies:
word transitions, or, matching duplicate punctuation to wiki markup
code, whichever it finds first, such as knowing that three apostrophes
toggles bold.
'''''5text = italics bold five text; which toggled first? Who knows? I
presume bold toggles first, then italics toggled. Let's test:
'''bold '''''5text = italics five text (no bold); implying the five
apostrophes were interpreted bold as highest in the hierarchy, so, of
the five apostrophes, the first three were considered a bold-toggle, and
final two were considered an italics-toggle.
''italics '''''5text = bold five text (no italics); implying bold again
wins, and the subsequent italics-toggle turns off italics as expected,
the pattern is, so far, predictable. But let's revisit four
apostrophes:
'''bold ''''4text = bold apostrophe normal four text, this makes no
sense. In the four apostrophe grouping, the first three should have
toggled bold, and the final should have been interpreted as text,
displaying '4text normal, but when actually displayed, the ' was bold
and the 4text was normal. Huh? THERE'S THE BUG!
''italics ''''4text = normal two apostrophe four text, again, in the
four apostrophe group, the first three should have been a bold toggle
and the subsequent apostrophe should have been text. Apparently the
parser holds the existing state of wiki markup toggle in it's head and
raises that in the hierarchy. Who does this programming, anyway? Let's
test italics on and off first, not just on first:
''real italics'' ''''4text = normal apostrophe, bold four text. This
SHOULD be the same as avobe, but isn't. Apparently we need to add one
more item to our expected parser function hierarchy, THIS IS WHAT THE
PARSER SEEMS TO ASK:
1 - is there a bold or italics toggle ON outstanding? (This surprised
me, I thought toggles ON and OFF were hierarchically equivalent, but
apparently a toggle ON creates a pressing need to look for a toggle OFF
before interpreting anything else!)
Then:
2 - have we reached the superior matching wiki markup text? (On other
words, ''' is superior to '' in the look-up-table.)
3 - have we reached a text word barrier or paragraph barrier?
(Supposedly, paragraph markers reset all toggles to OFF, but apparently
some wiki markup survives paragraph markers, or is it only HTML-style
markup using <markup></markup>-style coding that ignores paragraph
markers?)
Continuing the test:
''''''6text = italics bold apostrophe six text
'''''''7text = italics bold 2 apostrophe seven text
''''''''8text = italics bold 3 apostrophe eight text
... and so on.