rewrite and extend Caveats

[Larivact]

"inherent limitation in wikicode" sounds misleading it's about generating an AST instead of HTML. #179

[earwig]

This is good, but I would broaden the scope of the second bullet to mention other cases where template-sensitive information is unavailable. For example, if I created {{bold-end}} as </b>, then MWPFH won't parse <b>foobar{{bold-end}} correctly for the same reason. This often comes up in the context of tables—people like to construct table headers/footers from multiple templates but then use the raw syntax in the middle.

[Larivact]

I think {{bold-end}} would be a bad example since it doesn't make any sense.
Can you give me a simple example that actually makes sense?

[earwig]

https://en.wikipedia.org/wiki/Template:End

[Larivact]

I don't get it why wouldn't you just use |}?

[earwig]

Semantic clarity? I don't use it, but it exists.

[Larivact]

I fundamentally rewrote it. I think it's way more clear now.

[coveralls]

Coverage remained the same at 98.971% when pulling 2d89f61 on Larivact:patch-1 into d7c755f on earwig:develop.

[lahwaacz]

While you're at it, you could also add this (feel free to copy-paste):

• MediaWiki treats HTML comments in such a way that they can influence the surrounding elements (see Heading node should "eat" the following whitespace and newline #55 (comment) for examples).

And a paragraph about language constructs depending on the MediaWiki configuration. In particular:

• Localized namespace names are unknown, so for example [[File:...]] links are treated as normal links (see Text extraction from File: wikilinks has an issue #87 and strip_code() needs special case for [[File:...]] links and interwiki links #136).
• The suffixes for constructing word-ending links are language-specific, mwparserfromhell does not handle them at all (see filter_wikilinks does not work for links with added suffixes #82).
• Anything that looks like an XML tag is parsed like a tag, although MediaWiki recognizes only a finite number of tags. This can currently confuse the parser a lot (see Fallback on invalid tags? #102).

I only did a quick sweep through the existing issues, there might be more worth to mention.

[coveralls]

Coverage remained the same at 98.971% when pulling 4d4a251 on Larivact:patch-1 into d7c755f on earwig:develop.

[Larivact]

I renamed Caveats to Limitations since it's more descriptive and added a new "Configuration unawareness" section with the issues you suggested, only slightly reworded. I didn't add #55 since it isn't an inherent limitation (it could be fixed) and it isn't configuration-dependent.

[coveralls]

Coverage remained the same at 98.971% when pulling 2e486f7 on Larivact:patch-1 into d7c755f on earwig:develop.

[earwig]

Sorry, got a bit distracted and lost track of this. Thanks for helping out; I will accept this, make some changes, and update the web docs.