Ævar Arnfjörð Bjarmason wrote:
Why would it ever break? I can see it getting slow because it cannot be optimized but not breaking, all it's doing is just including one thing after the other
{{a}} gets Template:A which contains "foo" and {{b}} gets Template:B which contains "bar" hence
{{a}}{{b}} = foobar
Of course, this simple example would still work. But picture this:
Template:A contains: I ''li Template:B contains: ke'' hamburgers
currently, {{a}}{{b}} would yield "I <em>like</em> hamburgers", but only because it sticks the pieces together and then tries to make sense of it.
Why is this bad? Picture this:
Template:A contains: {| | nowrap Template:B contains: | Text |}
Is the "nowrap" a table cell attribute or text in a separate cell? Does this change depending on whether there is a newline after "nowrap"? ... And this is just a simple example.
Why would this break in whatever parser you plan to implement?
Because a parser is not a converter. The current not-really-a-parser is actually a converter: It looks out for particular syntax elements like ''these'' and turns them into <em>HTML tags</em>. This is bad because it means that several of these conversions can interfere with each other:
I ''like [[hamburger|hamburgers'']]
produces invalid HTML. It gets even worse when it tries to locate {{template inclusions}} and replaces them with some other text, not knowing what it is or how it fits into the document structure.
A real parser analyses the document's structure. It turns the wiki text into a data structure in memory that actually bears resemblance to the structure of the document. It creates a "heading" element where there is a heading, instead of turning some strategically-placed equals signs into <h#> tags.
The only reason i can see why that would happen is if you were to implement some auto-completion of the table syntax. Sort of like tidy(html) for wikisyntax and do it before things get fetched from Template: rather than after everything has been included.
Your terminology "auto-completion" reveals that you are thinking in terms of conversion. Don't think of it as auto-completion; for example, if a '' has no matching '', I can tell the parser what to do independently of what it does when there *is* a matching ''. There are several possibilities: make an italics element (what you would probably call auto-completion); make a text element (i.e. pretend the "''" was actually text); or bail out saying "syntax error". Of course, we don't want the latter. My parser currently does the second: It turns the '' into text. I did that because this is also how the current not-really-a-parser functions. However, I can easily change that.
In our specific case, there would be a document (a template) that has a {| with no matching |}. What should it do? Unfortunately, none of the three options make it work the way you have come to expect from the current not-really-a-parser.
Timwi