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
Extensions using Phan need to be updated simultaneously with core due
to T308443.
Bug: T308718
Depends-On: Id08a220e1d6085e2b33f3f6c9d0e3935a4204659
Change-Id: I47dad71df97f38c55550f71baf6dae67dbe0a2ba
Including an user options to enable/disable the scheme. Defaults
to false. Feature is only availible together with the new more
accessibile color scheme as the CSS depends on each other.
Set behind a new temporary feature flag.
Bug: T305027
Change-Id: I46d240a30eda5a1526ada1fe9b724f7b4594b426
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
Fixes the issue with the change handler not working.
Bug: T303767
Depends-On: Iee4c885f92dd9ec985a3f9fd92a2fafc00f2e9ff
Change-Id: Idb97a67f940eee69e09679196d0de71e76ef3672
A common issue, reported in VPI as Possible Thursday weirdness, with
source editor users using syntax highlighting is that the caret can
often be misplaced as to where the user selects. This PR adds code
to reload CM when loaded to adjust for this behavior.
Moved to after CM has finished initialising. Tested working.
Add another instance of codeMirror.refresh().
Bug: T305333
Change-Id: I9a81ffd41a3ba1321b7b5744ba096583cbb1d96c
Add support for enabling, resizing, and disabling the new
realtime-preview feature.
Bug: T293347
Bug: T303767
Change-Id: I8c8c25fe56be55a61f4b8d1d2ef8cf74483aa241
The resulting code style in this file is a little mixed. I tried to
stick to the existing style. Most notably is the indention with
2 spaces instead of 1 tab. But I couldn't disable the spaces inside
round brackets. They make the code so much more readable.
What this patch effectively does is enabling the eslint check for our
custom code in this addon, excluding all old code, and exclusing a few
rules that conflict to heavily with the old code style.
Change-Id: I12f953cb0a6fd35e405b6cc348abfb2c11e70696
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
Currently, only registered parser tags are included in the list of
extension tags to be highlighted. This patch allows extensions that do
not register their tags as parser tags (Extension:Translate) to still
define them for highlighting using the existing CodeMirrorPluginModules
annotation.
This patch also removes the special-casing for <translate>, as it can be
defined in Translate instead.
Bug: T284883
Co-Authored-by: Tacsipacsi <tacsipacsi@jnet.hu>
Depends-On: I860c944eaeeb7771629a1ed2352c05cfd8d7ca80
Change-Id: Iba2b0b874ebbace7a892af9e1d9896e8b17ade78
When CodeMirror is focused/blurred, the same event will triggered on its corresponding textarea.
Bug: T197632
Change-Id: Ib71b6774a60dd434bdc8a27b9eab433dcc1c65f0
HTML and extension tags should be highlighted as the text of internal or external links.
Bug: T184341
Change-Id: Ib1f2047936b395afd86720e2a7c921e382229cdd
