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
