Topic on 2017 wikitext editor/Feedback

I've recently been using the 'New wikitext mode' so I have access to it's enhanced syntax highlighting.

What would also be appreciated in terms of my "repair" edits would be integration of the search regexps that the tool here Wikipedia cleaner has for identifying CHECKWIKI repairs., There are other semi-automated edit scripts like auto-ed that would also be useful.

I'd also like to see consideration given to integrating something like User:PerfektesChaos/js/lintHint, given that it's currently not compatible with the mode.

Thanks for the suggestions. I think @NicoV is the best person to ask about whether WPCleaner can be made to run in this kind of environment. As for @PerfektesChaos's script, it's possible to install editing gadgets, but I don't know how easy it would be.

Hi. As WPCleaner is developed in Java, I see no wa to integrate it with the new wikitext mode. It would probably require developing a new gadget following the line given by Whatamidoing.

• It is a CodeMirror issue.
• 2017 VisualEditor source mode is involved only by serving a button, but 2006 or 2010 toolbar would have done the same with the similar button.
• On CodeMirror mode the original textarea does not contain the updated wikitext, and it needs to query from the CodeMirror architecture to retrieve the last updated wikitext.
• This weekend I deployed lintHint supporting both wikEd gadget and CodeMirror extension.
• Has been announced at w:de:user talk:PerfektesChaos/js/lintHint #Reporting incompatibility of LintHint.js with 'New wikitext mode' in Beta.
• It does not only evaluate the updated highlighted wikitext but also succeeds in positioning to the source text fragment in doubt.
• VisualEditor itself is not involved in linter business nor lintHint, since there is no wikitext present at client side.

And this update is activated how? I assume the documentation will also be updated?

I do follow a standard procedure:

• If it is a real bug, even more damaging texts, it is remedied and deployed asap.
• If it is a little improvement, it is published in debug state and a small group of test users will deal with that for half a day or a day.
• If there are no complaints a small step will be deployed then for all.
• If the step is very minor and makes no real change for users, deployment to all might be postponed and follows later together with more effective changes.
• If it is a quite big change with some risks (like the issue which is discussed here) the preliminary change will be published for a week before it is deployed to all.
• If that turns out to be stable and it is a major issue worth mentioning in documentation, it will be added one or two weeks later if no problem arrived.

Therefore it might take a month between a suggestion and the documentation of a change.

The update is performed by uploading new JS page contents. If browsers and servers would obey cache intervals it might take further days up to a week.