By default, this feature highlights unmatched brackets when the cursor
is placed over it. This can be disabled, but seems useful so we'll add
it as one of the new features in README and see how users react.
Bug: T348019
Change-Id: Ie6af715e40aeb8217a7c4dfe0c6e6a3dcfa725d5
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
This was working before somehow… but according to the CodeMirror docs,
it never syncs with the textarea automatically, so regardless this is
a necessary safeguard at least.
Repro steps:
1) Have CodeMirror turned on
2) Open a page for editing
3) Add content
4) Toggle CodeMirror off
With this patch, it should now always be synced.
Also add selenium test to ensure this doesn't break again.
Bug: T317243
Change-Id: Ie44e62fe5838bf32f40c6a3595ec3f541380cfe1
Since wikEd and DotsSyntaxHighlighter are both popular gadgets in and
outside WMF wikis, they are included in this setting by default.
Change-Id: If6c953858f9cf73024959b5a3b71b33ab7b48b4c
This fixes integration with some consumers of the
'ext.CodeMirror.switch' hook, such as Extension:Disambiguator.
The jQuery element passed to the hook is around the CodeMirror DOM
element which has the jQuery.textSelection() API registered to it.
Bug: T317243
Follow-Up: I2239d2449b2db3b638551f847eb4eff1aafa6276
Change-Id: Iec368613da3c69df52ce5e7ca441c31172cdc5de
Add a new $wgCodeMirrorV6 temporary feature flag that when enabled,
will load the 'ext.CodeMirror.v6.WikiEditor' module that is built
against CodeMirror 6. You can also pass in the ?cm6enable=1 query
parameter to force use of CodeMirror 6. This is currently only
implemented for the 2010 editor.
Due to packaging constraints with CodeMirror 6, we now use Webpack to
bundle the files, which are then used by ResourceLoader. This is similar
to what is done for Extension:Popups, MobileFrontend, among other
extensions.
A new generic class CodeMirror can be used on other areas where syntax
highlighting is desirable, but not necessarily for editing (i.e. without
WikiEditor).
This commit merely lays the foundation for CodeMirror 6 and updates
WikiEditor to use it. The actual MediaWiki syntax highlighting will come
with a future commit.
With the new Webpack build, the Gruntfile was removed and the tasks
moved to npm commands.
Bug: T317243
Change-Id: I2239d2449b2db3b638551f847eb4eff1aafa6276
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
Add core's change handler for CodeMirror changes as well, to
save in-progress edit data.
Depends-On: I32c13c1eeec55dc442b0a00ede9cb74422b0307e
Bug: T342882
Change-Id: I352470752130c7b9b2dfc55a066cecf785d40067
This removes the need for the init module.
Bug: T340751
Depends-On: Ibcc81c90bc9ba6c5fd012c512daf861973b03b2e
Change-Id: Iec3a4c6b00288aee376af47e778c4aa67a98d29b
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
Get rid of the flag, without making any substantial changes to the
code. A follow-up commit will merge the CSS into base rules.
Bug: T307188
Change-Id: I601df5047d0db3cfb9559538487d3d39bb6c7cf4
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
Fixes the issue with the change handler not working.
Bug: T303767
Depends-On: Iee4c885f92dd9ec985a3f9fd92a2fafc00f2e9ff
Change-Id: Idb97a67f940eee69e09679196d0de71e76ef3672
