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
User-options related classes are being moved to the MediaWiki\User\Options namespace in MediaWiki Core; reflect that change here.
Bug: T352284
Depends-On: I9822eb1553870b876d0b8a927e4e86c27d83bd52
Change-Id: Ib0022571e750becc87c56adcb2d5bdb203b6254d
Some users actually use CodeMirror and DotsSyntaxHighlighter, and
according to them and my own testing, there is no actual conflict. As
such, we shouldn't prevent CodeMirror from loading when this gadget is
enabled.
See https://w.wiki/8J4J
Follow-Up: If6c953858f9cf73024959b5a3b71b33ab7b48b4c
Change-Id: I259737d27cc3190fbdc335da2ccd471fcc0cff8b
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
Consistently use
$this->getServiceContainer()
instead of
MediaWikiServices::getInstance()
in tests.
Also use namespaced classes
* MediaWiki\Output\OutputPage instead of OutputPage and
* MediaWiki\User\User instead of User.
Change-Id: I0cc39ba6cc706bf01581687e440ef9fb4ad39d81
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
Tests that create a user account actually use the database and
most be marked as such or they will thow an exception.
See Ic4a72fbfaee730b8417848ae0603443d4995fefc
Change-Id: I827b536006130c9813a2a079eab01be112e691be
Add core's change handler for CodeMirror changes as well, to
save in-progress edit data.
Depends-On: I32c13c1eeec55dc442b0a00ede9cb74422b0307e
Bug: T342882
Change-Id: I352470752130c7b9b2dfc55a066cecf785d40067
