Magnus Manske wrote:
Same problem again. You can use this old text: http://www.bliki.info/test.txt
Fixed. There was a heading like "== stuff == " (note the final space), which, strictly speaking, is broken (yes, I'll make it recognize it anyway soon).
So the parser tried to fall back to rendering it as a "normal" line (not as a heading), which it couldn't do because the line starts with a "=", which indicates a header line.
I've added a fallback to force it to render as normal text now. For what it's worth, I've just successfully converted [[de:Mainz]], >140KB of text. Took 52 seconds but, well...
A suggestion on this kind of error:
I think the best behaviour is to try to work out what the user intended, but not correct it in the parser, because without formal definition and when a parser is used as the reference of the language anything it doesn't mark as an error becomes valid syntax.
In my parser I output errors like this:
This is <b>not well formed
<paragraph lineno="0" charno="0"> This is <wikiwyg:syntax-error type="close missing"> html:b/ </wikiwyg:syntax-error> not well formed </paragraph>
and:
There is no such character entity as &wumpus; <paragraph lineno="0" charno="0"> There is no such character entity as <syntax-error type="unknown entity" name="wumpus"> <char-ref name="wumpus"/> </syntax-error> </paragraph>
So I detect what the user was trying to do, but not correct them. Correction is done in a layer between parser and presenter.
Firstly, this provides a separation of interests that if done right can make the parser much simpler, but it also allows a user to choose to have syntax errors not corrected and shown on the page so that imperfect articles can very easily be seen and fixed. See:
http://users.aber.ac.uk/jqh1/err_bold.png http://users.aber.ac.uk/jqh1/err_wumpus.png
Jim
-- visit my new wiki engine - http://81.5.150.113/wysi