Welcome to Creole, we are glad you are with us.

Your comments on quotes are very helpful, I didn't know about that mozilla guidelines. Seems like you have some very good ideas.

I'm impressed with your parser, it can even handle things like {{{//italic **bold italic// bold**//}}} and generate proper html for them!

However, it behaes weird on this input:
{{{
[[some
link|some 
text]]
}}}

-- [RadomirDopieralski], 2006-09-24

----

Thanks a lot for your help, Radomir. I worked on the problem of newlines in links and it should be fixed now.

About the parser: large part of the code is taken from Text_Wiki, so its developers are the people who deserve your compliments. But... thanks! ;)

-- [MicheleTomaiuolo], 2006-9-24

-----

Seems something has changed for the worse as {{{//italic **bold italic// bold**//}}} produces {{{<p><em>italic <strong>bold italic</em> bold</strong>//</p>}}}.

-- Jared Williams, 2006-09-25

----

You're right, Jared, the parser is not yet so smart to avoid this kind of crossing elements. This could also involve links. Radomir, I suspect you used "View selection source" in Firefox... Is it possible?

These cases cannot be easily recognised in Text_Wiki using regular expressions. The only solution I can imagine is counting the tags (actually 'tokens' generated by previous rules) inside the body of a new found element, to avoid encapsulating a single opening or closing tag. Any suggestion?

-- [MicheleTomaiuolo], 2006-9-25

----

I've added a check on the the inner tags. At least the generated XHTML is standard compliant, now, even if in convoluted texts some possible elements could be missed by the parser.

Thanks everybody for helping and finding bugs. Be patient as it's just an early release.

-- [MicheleTomaiuolo], 2006-9-25

----

I'm using DOM to build the XML/XHTML, thereby ensuring the output is atleast XML compliant. Here is my current method for handling bold.. 

{{{
case '*':
    if ($i < $l && $string[$i] == '*')
    {
        ++$i;
        if ($parent->nodeName == 'strong')
            $parent = $parent->parentNode;
        else if ($parent->nodeName == 'em' 
                && $parent->parentNode->nodeName == 'strong')
            $parent = $parent->parentNode->parentNode;
        else
            $parent = $parent->appendChild($doc->createElement('strong'));
    }
    else
        $this->appendText($parent, '*');
    break;
}}}

So for input of {{{//italic **bold italic// bold**//}}}, it'll currently output {{{<em>italic <strong>bold italic</strong></em> bold}}}.

But I'm unsure if this should be improved upon. Perhaps the strong should be re-opened after the closing em, as in {{{<em>italic <strong>bold italic</strong></em><strong> bold</strong>}}}.

-- [JaredWilliams], 2006-9-25

Yes, I used the 'view selection source' in firefox, shame on me, forgot it does some tidy-ing.

As for support for crossing the tags -- it's not needed. [Creole] says that this is not allowed, so the output is not defined -- of course, as it should be [NonDestructive] markup, you should display __something__, and it's nice if that something is valid (X)HTML. I think that {{{<em>italic <strong>bold italic</strong></em> bold}}} is reasonable.

-- [RadomirDopieralski], 2006-09-25

----

I agree with Radomir:

* silently correcting wrong markup could encourage users' bad habits;
* wiki syntaxes, and Creole in particular, should use [ReadableMarkup] - so, no harm in leaving text untouched ([NonDestructive] behaviour).

I think some feedback or warning to the user would instead be useful.

-- [MicheleTomaiuolo], 2006-09-25

I don't know why, but I cannot edit [[Engines]]... PEAR Text_Wiki_Creole is 0.4 compliant.

-- [[Michele Tomaiuolo]], 2007-02-04

I cannot edit [[Terms]], too. Am I considered a spammer? I think I behave :)

Anyway, I cannot understand the meaning of the unified list in that page. IMO, having separated lists, for chars used by Creole and those not used, was more useful.

-- [[Michele Tomaiuolo]], 2007-02-06

There is some bug appaearing now and then preventing the editing -- you're not considered a spammer or anything like that.

As for purpose of the list, the title says it: it's to explain the terms we use to talk about the markup. Since the terminology is not widely know or even stadarized.

Two lists could have been useful if they were up to date, and possibly linking to where the character is actually used...

-- RadomirDopieralski, 2007-02-06

Thanks Radomir, I see. Probably we'll improve the list later, when specs will be more mature.
About editing, I was mostly jocking: I supposed there was something wrong about ACLs or about my profile.

-- [[Michele Tomaiuolo]], 2007-02-06