This removes treating an HTML entity in a template name as a separate
token, and thus deprecates the .cm-mw-template-name-mnemonic CSS class.
In CM6 we have to register tokens for them to show, and this one seems
of little use to begin with. HTML entities should always be styled as a
such, especially in page titles where they are treated post-processing.
i.e. [[/dev/null]] links to [[/dev/null]].
The rename to .cm-html-entity and associated code is to better reflect
what it is. $rarr; is a mnemonic form while / is not, but both are
entities. Deprecations are noted in the README, with the old classes
to be removed later after on-wiki usage has been updated.
Bug: T348019
Change-Id: I1184fb5d7d37084c80af1abd5f3cb5f2091b085c
Presumably it was always the intention that tokens with the styles
.cm-mw-page-name AND .cm-mw-em should be both bold and italic in links,
without having the CSS rules override each other. As an example:
'''''[[Bold and italic title]]'''''
Added a note in the README that this will be a new user-facing feature
Change-Id: Iac41e31b7a9cf8683cd5c982c496ff83a092acfb
This merely ports over Ica3fb110ce and Id5e50c2baf to the CM6
stream parser. Also port the test that was added in I7907b4743b
Bug: T292967
Bug: T348019
Follow-Up: Ica3fb110cebb5650f66be321b533ed030e2c9698
Change-Id: I54b1624131ea63f403ebc1f6f900556ca868b7f4
This is more or less a exact port of the old stream parser, with the big
notable change being that all configuration-related code lives in a
separate class, CodeMirrorModeMediaWikiConfig. A smaller change is that
closing HTML tags that are marked as errors now have the ending '>'
character highlighted red, when it didn't before.
Integration with other extensions and modes is saved for a future patch
(T348684). This means <nowiki>, <ref> and other extension-supplied
markup is not yet highlighted.
The entry point for WikiEditor integration is now at
ext.CodeMirror.v6.WikiEditor.init.js, which needs to first require the
virtual file set via the DataScript (PHP) class. This can't be
integrated into the CM6 code because it needs to be precompiled before
ResourceLoader can use it (T281781).
Known issues, to be addressed separately:
* No support for TagModes / PluginModes (T348684)
* Identical adjacent tokens produce excess markup (T352917)
* Section headings do not have line-level styling (T351686)
Bug: T348019
Change-Id: I8f8a81f362bed60dea14ecde9487a2b0c89225e8
These methods will be used by other modes and/or extensions,
and as per the frontend stable interface policy, they should
be marked as stable.
Also permit callers to pass in a HTMLTextAreaElement, jQuery
object, or a CSS query string.
Change-Id: Iec57bf8fe4086faf57b3cc10834baaa27af80b85
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
