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
Move WikiEditor-specific code to ext.CodeMirror.WikiEditor, leaivng only
CodeMirror-specific things in ext.CodeMirror, including the logUsage
method which was duplicated in the VE plugin and now refactored.
Add .env to .gitignore so that selenium tests can be ran more easily
This patch leaves the other non-mediawiki modes still using the
'scripts' system instead of 'packageFiles'. These are not used in
MediaWiki directly but by some extensions (i.e. PhpTags) and using
packageFiles will break that integration.
Bug: T272035
Change-Id: I3bafef196c1f713443d7b8e9cb7dc2891b379f5d
It makes no difference to directly assign Codex Design System for
Wikimedia colors as values instead of re-assigning the outdated
`@wmui-color-*` variables.
Bump to required MediaWiki core version >= v1.41.0.
Also put stylelint-disable before the block it's actually needed.
Bug: T334934
Change-Id: I5696f160d39ef4edec7a1b966fe7e73608c86bdc
Note that this .match() method is not the one you think it is.
This is StringStream.match() from the CodeMirror lib, not ES
String.match().
Change-Id: Ief5048ff78bcd035482e7a68044e24592d28cb6c
I did some reverse engeneering and derived the three base colors for
nested templates and parser functions as well as links, together with
a formula to calculate any mixture of the three.
You can manually compile the .less file:
lessc resources/mode/mediawiki/mediawiki.less resources/mode/mediawiki/mediawiki.css
Then compare:
git diff --word-diff=color -w HEAD^ -- resources/mode/mediawiki/mediawiki.css
You will see that some numbers change. These are rounding errors in
the old .css code.
Bug: T307188
Change-Id: Ic534a2fac73f9f737ae5238b87aa80b705b37786
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
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
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
HTML and extension tags should be highlighted as the text of internal or external links.
Bug: T184341
Change-Id: Ib1f2047936b395afd86720e2a7c921e382229cdd
* 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
Adds a custom class for matched brackets to allow better integration
with custom bracket styles. The brackets won't be bold in the 2017WTE.
Bold font might lead to misalignment there. See ticket.
Note: box-shadow seems to be supported for quite some time by all
relevant browsers
Bug: T270926
Change-Id: Ica1e301f63a106a96db3bfaba4b2f322af64b009
These changes to the color scheme are hidden behind a feature
flag for the time being.
Bug: T271895
Change-Id: I0a4b03e0f3bc8239f31edbbd5ae55661607b76f6
I was wondering why the performance when editing wikitext is
still so bad, and profiled it again. Turns out
StringStream.match() is still the bottleneck (even if already
100 times better than before Icbb1122).
The method is called with many different patterns from
mode/mediawiki/mediawiki.js. I profiled them individually and
found a single outlier. The idea is the same as in Icbb1122.
A pattern that is able to find something *in* a string is
doing nothing but wasting time, as StringStream.match() ignores
every result that is not at the start of the string.
The change adds the missing ^ anchor and wraps the regex pattern
from mw.config.get( 'wgUrlProtocols' ) (that is something like
"ftp:\/\/|http:\/\/|https:\/\/|…") in (?:…), which is a
non-matching group. This is necessary because of the | in the
pattern. The result is a pattern that looks like /^(?:…|…|…)/i.
I remember looking at this code while working on Icbb1122, but
didn't include it in the patch, and then forgot about it.
Bug: T270237
Bug: T270317
Change-Id: Iea2fd116b68704c3186b0edf965006cc7c6eda82
I continued profiling the matchbrackets addon for T270237 and run into
performance issues that turned out to be unrelated to the addon. The
flame graph highlighted a "match" function. Note this is not the
String.match() from JavaScript, but something in the CodeMirror lib:
StringStream.prototype.match = function (pattern) {
var match = this.string.match(pattern);
if (match && match.index > 0) {
return null;
}
return match;
}
(Note: I simplified this code so we can focus on the bug.)
When the pattern is a regular expression, it's executed via
JavaScript's String.match(). The function then checks if there was a
match and if it's at the start of the string. If not, it's not a
match and doesn't return one.
In other words: Even if there is a match somewhere in the string, the
function acts as if there was no match.
When we change all patterns to be anchored via ^, they don't scan the
entire string any more but return much ealier when there is no match
at the start of the string. We are effectively replacing nested loops
(hidden in the patterns) with single calls.
This bug exists since 2014.
The disabled line in the matchbrackets addon is just dead code. I
don't remove it to document the fact that we disabled it.
Bug: T270237
Bug: T270317
Change-Id: Icbb1122e6a3b26c0606726ff405e108931d185be
I had to make some CSS selectors more specific, because the
library changed
.CodeMirror pre
to
.CodeMirror pre.CodeMirror-line,
.CodeMirror pre.CodeMirror-line-like
This is only relevant for entire lines (implemented as <pre>
elements). Most of the custom CSS is for characters, not lines.
In my tests in the Wikitext editor as well as VisualEditor I
could not spot any difference between the old and new version.
Bug: T258999
Change-Id: I6f0f030f972838727f3ef220feb105264f122798
The rgba() syntax is supported for a very, very long time now:
https://caniuse.com/#feat=mdn-css_types_color_alpha
Notes:
I realized the numbers in these file names are actually their
transparency in percent (more precisely their opaqueness).
4 is 4% which translates to 0.04 in the rgba() syntax.
I used Gimp to pick the opaque color values from the images.
Gimp makes this easy. No guesswork or calculations needed.
For multiple, stacked images I calculated the colors by
averaging their RGB values (considering how opaque each color
is). Note this is actually *more* precise than the stacked
images before. Stacking alpha colors is flawed. For example:
Let's say we have an rgba(255, 255, 255, 1) background.
Layering a half transparent rgba(255, 0, 0, 0.5) on top means
half the background shines through. This averages to
rgba( 255, 127, 127, 1). Now we stack rgba(0, 0, 0, 0.5) on
top. Again, half the background shines through, resulting in
rgba(127, 63, 63, 1).
When we apply the two colors the other way around, the result
is rgba(191, 63, 63, 1), a much brighter red.
This flaw doesn't happen when precalculating the averages, as
done in this patch.
Change-Id: I29026864714c5f90c2613af57f08693e7e2b996c
