In T69074#737261, @Rillke wrote:

after increasing memory to 204800 and restarting apache, it no more failed thumbnails for that reason -- still needs investigation

There is a few more errors because PHP 7.1 is more strictly related to the type of data, it is good but I need to process these incidents inside phptags too,
for example
php5.5 php7.0:
["4"] & "fff"; is ok
php 7.1
["4"] & "fff";

PHP Warning:  A non-numeric value encountered in Command line code on line 1

@hashar, thanks for looking at the failures. I debugged the problem, it happens because PHP 7 assigns the values in the list operator in reverted order (link).
I'll fix it soon

please, check it https://gerrit.wikimedia.org/r/#/c/435971/

Oh, sorry for delay, I try to update it right now

Oh, sorry. I got hard busy... I hope to continue in 2-3 weeks :-/

! In T174145#3652265, @kaldari wrote:
Note that we have to use an OOjs-UI icon for syntax highlighting within the 2017 Wikitext editor. That interface is constructed using OOjs-UI, so the only choices we have are the icons in https://github.com/wikimedia/oojs-ui/tree/master/src/themes/wikimediaui/images/icons.

looks like a virus :)

Seems should be fixed. Should be used different keyMaps for Mac and PC.

the path was rebased to the latest version of CodeMirror where the mentioned bug is fixed.

The status was changed by mistake... I did not want to do it by myself

ctrl + arrow key still working. Change 373624 makes behavior of alt + arrow key the same as when textarea used, see bug T174055.

Home / End keys cumbersome behavior

I think there should not be a big problem to make it resizable, and there should not be a problem with performance. I'll try to fix it.

can't reproduce on en.wikipedia.org

@Niharika yes, I understand about cost. I would prefer to find a balance between speed and ease of use.

Seems should be fixed with T174547

Should be merged with T174514

There is a bug: Home after End goes to the start of the next wrapped line. Hopefully it was fixed in latest CodeMirror library.

Solution is Better Home/End navigation with wrapped lines? #1576

The bug in the CodeMirror library Paste by using middle click in firefox not working #931

Maybe try to set viewportMargin to Infinity when ctrl+F pressed?

As a variant the patch above calls the CodeMirror.enabled and CodeMirror.disabled hooks.
Catching ones gets you full access to the CodeMirror features.
For example, alert message when the text is changed:

mediaWiki.hook( 'CodeMirror.enabled' ).add( 
    function ( cm ) { 
        cm.on( 'change', function() { 
            alert ( 'text changed' ); 
        } );
    } 
);

It used event change of CodeMirror.

Not sure for what the one was added by change 199941.

@Niharika I'm on a trip until September

Can't reproduce on en.wikipedia.beta.wmflabs.org

The bug described above happens on FF. Since WikiEditor does not designed to work with changeable icons, the one requires the icon defined when initializing. Because we use other approach to define the icons, WikiEditor inserts style to the button style="background-image: url("undefined");".
Despite the fact that it is removed later, FF trying load undefined background any case .

Possibly there is one other problem, I see the requests to /w/undefined when CodeMirror is enabled. Maybe problem is only on my test wiki, please check it on before the wide-scale deployment.

@Niharika It is easier to install the extension without composer usage and maybe when I created the extension composer was not widely used for mediawiki extensions (not sure).

@Niharika Maybe it is possible by process event:

"cursorActivity" (instance: CodeMirror)
    Will be fired when the cursor or selection moves, or any change is made to the editor content.

There are two problems:

1. font size can be changed only for whole line and big comments looks ugly for me.
2. processing comments required some optimizations of tokenizer, it should be able to change type of previous tokens without processing all next tokens again.

Take a look at my solution, maybe you'll find there something useful.
https://github.com/pastakhov/compose-mediawiki-ubuntu

Seems there is a hook that are called when Toolbar initialized, I am not sure...

Thanks for nice links ;-)

Yes, actually it is one task - make parser for [[File:...]]. One is parsed as a link still.

Wikitext syntax highlighting depend on mediawiki settings such as site language, extension installed and etc.
Thus it is not possible to make a general mediawiki mode аnd in the future this dependence will only increase.

@IKhitron, It does not work since there are only part of language aliases (localized magic words).
And as I wrote, I have no idea why there are only part of them.
In any case this behavior is a bug, CodeMirror should use only language from $wgLanguageCode and it will be fixed soon.
For check localized magic words you should set $wgLanguageCode to corresponded value or use the CodeMirror extension on wiki with $wgLanguageCode have corresponded value (it's no joke).

I found other way - add uselang parameter to url, but it is more a bag that a feature (and should be fixed)
For example https://test.wikipedia.org/w/index.php?title=Pride_and_Prejudice&action=edit&oldid=323245&uselang=de
Or change it by language toolbar at the top of page. But in this case I see only part of language aliases.
Have no idea why.

I meant that it depends on the value of the $wgLanguageCode variable.
On test.wikipedia.org it is en thus there are no Localized magic words.
For check localized magic words you should set $wgLanguageCode to corresponded value.

Such hard-to-reproduce bug report is like a diamond, thank you for testing and well describing.
Seems problem is in $( addCodeMirrorToWikiEditor );
The addCodeMirrorToWikiEditor function should be called after wikiEditor loaded. (should make sure that wikiEditor loaded).
This is really hard-to-reproduce.

Feel free to reopen the ticket if it will not work on local wiki

This is the expected behavior.
Localized magic words should be highlighted only on local wiki.
As you see, MW parser interprets them as Template:SORTIERUNG:AA and Template:מיון רגיל:AAA

@IKhitron the problem is not the same like a template inside a template and solution will be different.
Files have their own syntax and I just skipped this part of code (I had no time)

@Niharika no, it is not a complicated problem. Just Files contain several different parameters (not only the caption) and it takes a time to write code to cover all them. I will fix it.

Can't reproduce.
Tested on CPU Intel Core i5-2430M CPU @ 2.40GHz
FireFox 52 and Chrome 51 on Linux 64-bit.

I cant replay the problem
I took the large article and copied one several times for increase size of article even more.
Then I moved from beginning to end of article using mouse and ctrl + end buttons and could not see any "gaps".
http://test.foxway.org/w/index.php?title=Sandbox:T164809&action=edit

I will be able in a couple of days and take a look on it.

I have the old path for testing https://gerrit.wikimedia.org/r/#/c/323361/1 it may be merged

Skin is still in development, and it will be released.

Patch Set 3: use the color `#36С for the enabled button
Animated (3s)

Also background colors in tags and templates reserved for tag matcher.
For example when the cursor on or inside a pair of tags the CodeMirror highlights them. Demo

• I use mirrored background of toolbar, should I use one color #36C?
  • This is not possible by standard way since buttons are padded. As I wrote, I can try to hack it but seems it not good idea.

Buttonns in classic toolbar:

@Volker_E From my point of view, we need several themes T163533 in any case, and the question is which one to use by default. The one that will be more convenient for most editors or one that will be readable by all.
And why aren't we getting input from real Wikipedia editors? I reason more as a software developer, and maybe for Wikipedia editors it's actually more important to read the comments than to easily separate they from the regular text.

@Volker_E IMO comments are inherently very close to part of an inactive user interface component (in Incidental) that is excepted from requirement to have a contrast ratio of at least 4.5:1.

I agree with everything except the color for comments.
#72777d looks very good but it is a problem. It looks too organic, and it does not allow you to easily visually separate the plain text and comment text. Of course this depends on the used fonts, display, light, settings and tastes, but IMO #72777d is too close to having a too low contrast.
Perhaps, as a compromise we could use # 969696.

I'm sure we should do the code inside SyntaxHighlight

@Niharika The CodeMirror and SyntaxHighlight solve different tasks in different ways and one can't replace the other. We can make the text in the editor look the same as on the page (I mean the text or code inside <source> tags)

Not sure about icons. Originally the colored icon was displayed when the CodeMirror was disabled and the colorless icon when CodeMirror was enabled. It meant that clicking on colored icon makes wikitext color, and clicking colorless icon makes wikitext colorless...
Maybe the question for T163919

Patch already exists

@Niharika, it already exists by using CodeMirrorGetAdditionalResources hook , the problem is in performance only. I sure it should be rewritten for use in production. And yes, it can look ugly bu only if someone does it ugly, and, as I know, code review before merge prevent to merge ugly code to repository.

Integration is needed only for highlighting text (or maybe errors in the syntax) inside extension tags.

I wonder if we could just output the list of valid tags to the client

@kaldari, CodeMirror already gets the list of valid non-HTML tags from Parser.

It never occurred to me that for someone it might be better that all the tags be the same color :)
I think we should make several color themes (T163533) in the future and editors will be able to choose the best for themselves.

@DannyH, should all tags be green? There are HTML tags (like <big>) and extension tags ( like <ref> ) and specific wiki markup tags (like <nowiki>)
Originally HTML tags (and specific wiki markup tags except <pre> and <nowiki>) was green and extension tags was violet. I did this to visually separate HTML tags and extension tags since it look similar but behavior is different.

@Niharika, I saw the patch (Patch Set 2), it is incorrect (please take a look at my answer in comments )
Patch https://gerrit.wikimedia.org/r/#/c/346499 makes <pre> and <nowiki> tags green, and also allows extensions to define colors for own tags.
(I was sure by mistake that this task for <pre> tags. I have to be more careful)