On Wed, Nov 14, 2007 at 11:33:39AM -0500, Brion Vibber wrote:
Note also that it *is* a requirement to have sane
behavior with this
sort of construction:
L'''idée'' <- apostrophe followed by italics
L''''idée''' <- apostrophe followed by bold
That's a *requirement* to continue to properly handle French and Italian
text. The current apostrophe pass handler uses I believe a lookahead and
then goes backwards, which is a fairly sane way of doing this. If EBNF
can't handle it, then forget EBNF.
Can someone tell me why bold and italics are considered *part of the
spelling of the word* (which seems to be what you're implying here)?
I've never seen that to be the case in any character-based natural
language.
I could accept
that the first
sentence of my second part is "basic syntax". But not this kind of madness:
# If there is an odd number of both bold and italics, it is likely
# that one of the bold ones was meant to be an apostrophe followed
# by italics. Which one we cannot know for certain, but it is more
# likely to be one that has a single-letter word before it.
That's why we're proposing *adding* ** and //, to provide alternative
mechanisms for these complicated situations.
Let me be very very clear here.
Whether or not we ever add ** and // as bold and italic syntax is
completely unrelated to the actual task of rebuilding the parser or
speccing out a grammar for the wiki syntax.
If you want to play with alternate syntax (adding different markup such
as "**" or "//" or "$*^#&*^"), feel free to do so on
your own, but
please don't mix it into any discussion or work or planning or
decision-making about the parser.
New alternates aren't even needed; old alternates already exist (<b> and
<i>; use of <nowiki></nowiki> as a hidden separator, etc). Other sorts
of magic characters might also be neat additions, but they should not be
considered at this time because it's just going to sidetrack things.
You're correct.
Failing to replace the apostrophe mangle with something less ambiguous
pretty much dooms the entire project of attempting to build a formal
spec of the language, which seems prerequisite to implementing a newer,
less complex parser therefore.
Don't complicate the situation by tossing in new
stuff. Then the
conversation goes from something manageable (does this proposed parser
technically accomplish the job?) to something unmanageable (should we
make a large number of changes to markup?) and we'll never get anywhere.
Circular argument: we cannot decide if a replacement parser
"technically accomplishes the job" until we decide *what the job is*,
which requires *some sort of formal specification of the
markup*, whether it be in BNF, EBNF, or something more complicated than
that.
Since it does not appear to be possible to *create* such a spec to
describe even the *desired* interpretation of the current behaviour,
much less what the current parser actually *does*, I'd say we're back
to dead in the water.
But let's be clear on why, shall we?
Cheers,
-- jra
--
Jay R. Ashworth Baylink jra(a)baylink.com
Designer The Things I Think RFC 2100
Ashworth & Associates
http://baylink.pitas.com '87 e24
St Petersburg FL USA
http://photo.imageinc.us +1 727 647 1274