It's impossible to have a template that has the character { as part
of the name. The real-world example explained in T292967 is the
sequence {{{!}}. The old code detected this as:
* A template that starts with {{
* The template name is {!
* Template ends with }}
New behavior as proposed in this patch:
* A single { with no special meaning
* The parser function {{!}}
Note this is only a very small improvement, but doesn't fully solve
T292967.
Bug: T292967
Change-Id: Ica3fb110cebb5650f66be321b533ed030e2c9698
Variables like {{{foo}}} with 3 brackets typically only appear in
templates. But odd combinations of other features that also start
with 3 brackets are much more common. These should not be detected
as variables.
1. When something starts with 4 or more brackets it's not a variable
but something else. E.g. the start of a template where the template
name is a variable (2 + 3 = 5 brackets).
2. Tables can start with {{{!}}.
Note this doesn't fully solve T292967 but already improves the
situation a lot.
Bug: T108450
Bug: T292967
Change-Id: Id5e50c2bafb35a211d4b63609126c40b32f06a64
When there are standalone special characters '<', '[', '{', and '~' in the section header, the ending '=' will not be highlighted while the ending characters in the next line are incorrectly highlighted. This is because the ending '=' is eaten as plain text at the end of function eatWikiText(). A less aggressive plain text matching does not hurt.
Bug: T309143
Depends-On: I47dad71df97f38c55550f71baf6dae67dbe0a2ba
Change-Id: I4a9c6c6cb2f7fbc212808e386124a56676fdbfb1
Turns out the MediaWiki parser behaves odd when confronted with syntax
like this:
<ref name="a>b"> … </ref>
XML and HTML parsers are usually expected to respect the pair of double
quotes. But our parser doesn't. What it actually does is this:
<ref name="a"> b"> … </ref>
This change makes the syntax highlighter behave the same. This makes it
easier to spot this issue when editing wikitext.
Bug: T270880
Change-Id: I14bdf6630889fb6d0dea53890a693f00d9356f54
CodeMirror is already able to highlight multi-line tags if the tag name is followed by any non-whitespace characters in the same line. This commit fixes the other condition where the tag name is followed by whitespace only in the same line.
Bug: T201684
Change-Id: I8cb4a53ee0fe7fc8612a58331a1a3e57d00d7630
* What we care about is the <pre>. The class="CodeMirror-line" is
added to every <pre>. We don't really learn anything new when we
include it in our tests.
* Testing the ARIA role is testing a CodeMirror feature, not a
feature of the mediawiki mode under test.
Change-Id: I33bfedb304228240c4e835cc983117668c398c61
I forgot this when I added this test case in I03a1e1a.
Also:
* Use another method to detect if the Cite extension is active. This
is the same method used in the actual code.
* Move a line of code into the `if` it belongs to.
Change-Id: I1efd3f945150aeb08db3c771e579d9a6114a4c21
* Append to the hidden #qunit-fixture instead of directly to the body
* Use the right selector when cleaning up
Change-Id: I8be38900e6c5f4592f06dfc8f7c2cfc348627716
In T270880 an example with a slash in <ref name="a/b"> is
described. The same issue happens with several other characters
including the closing bracket, e.g. <ref name="a>b">. This patch
fixes all of this by accepting _all_ characters between double
and single quotes.
Bug: T270880
Change-Id: I03a1e1a25af692dc703b44a57b2d23d6fc15c8c9
CodeMirror inserts
style="padding-right: 0.1px;"
only on Webkit.
The test case now strips this pattern from the rendered HTML before
comparing with the expected test case output.
Change-Id: I34b201f790d3d85a5f51d8200bf8219f11d14506
