Page MenuHomePhabricator

Integration of CodeMirror with other tag extensions
Closed, ResolvedPublic


Wikitext syntax highlighting depends on extensions used, since extensions can enhance the wikitext parser adding their own tags and parser functions. And since only an extension knows about syntax that are used inside it own tags or parser functions, one should provide own modes for text highlighting, otherwise it will displayed as is (plain text).

CodeMirror uses hook CodeMirrorGetAdditionalResources that allows extensions to integrate with CodeMirror.
Example Cite, PhpTags
Seems this is not the best performance solution.

I think the better way is allow to integrate through extension.json file.
I know only one possible way to merge several values from different extensions (such as list of resource modules required for CodeMirror) , it is global variable (config property in extension.json) but it seems too ugly solution..
Seems extension schema should be extended with CodeMirrorResourceModules property...

As I see the better solution:
Extensions will create resource modules for CodeMirror and register ones in extension.json files (as ResourceModules)
CodeMirror will call a hook for get list of such modules from extensions (it will very cheap and only for edit page cases) or in the future list of CodeMirror modules can be integrated with extension.json file.
CodeMirror loads the modules and they will add information about how to highlight text inside extension tags.

Event Timeline

Restricted Application added a subscriber: Aklapper. · View Herald TranscriptApr 18 2017, 6:55 PM

This solution won't scale if there are fifty extensions creating tags and most of them are unmaintained, which is the case usually. Not many people will bother to add styling for their own tags in their extension. And even if they do, most people won't give any thought to how that will appear when their tags show up with tags from other extensions. It might end up looking like a total mess. It might be completely unsupported for people who are color-blind.

I'd prefer centralizing everything in CodeMirror.

What we can do is to somehow define a "default" color for <tags> , {{templates}}, {{#parser functions}} etc. and let extensions override them if they so wish. I am not sure how easy/complicated this solution is, but it certainly is better than waiting on every extension to provide their own styling.

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

Not many people will bother to add styling for their own tags in their extension

It is not required for all extensions. Only for most popular extensions where highlighting text inside extension tags may be useful.

It might end up looking like a total mess

Yes, this makes it possible to make a total mess, but who and for what will do it?
I'm sure that if extension developers want to take advantage of this opportunity, they will try to stick to some standards, and not make a mess. Therefore, I do not think that it is necessary to somehow impede this.

It might be completely unsupported for people who are color-blind.

T163533 should help.

I'd prefer centralizing everything in CodeMirror.

The possibility of integration is required in any case.
It is required for extensions that not popular and not maintained by WMF (for example the PhpTags extension)
Also syntax of text inside extension tags for different version can be also different. In this case version of CodeMirror will be tied with version of extensions. But wiki sites can use different set of extensions with different versions.

I am not sure how easy/complicated this solution is, but it certainly is better than waiting on every extension to provide their own styling.

This solution already used in the CodeMirror extension.
I am not waiting that every extension will provide their own styling, I say about the possibility only to do it.

Pastakhov updated the task description. (Show Details)Apr 21 2017, 7:08 AM

@Pastakhov Let's hold off on the extension integration for a bit? The thing that's bothering me is that if two or more extensions end up defining same/similar color schemes for their tags, it can look ugly. It's not deliberate but people use wikitext in lots of weird crazy ways. We should give this a little more thought before implementing it.

DannyH added a subscriber: DannyH.Apr 25 2017, 8:28 PM

@Pastakhov Yeah, I'd like to know some more about this. Do you have examples of extensions where developers might want to change the styling, and what they would want to do?

@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.

For example, take a look at CodeMirror library themes
CodeMirror contains many modes (over 100) and there are no problem with color themes.

This solution should allow extensions to use exist modes or create a new mode for highlight text inside their own extension tags.

@DannyH, yes, I wrote the PhpTags extension, there text inside <phptag> is php code. example. Without highlighting source code is hard readable for human.
Also the Cite extension parses text inside <ref> tag as wikitext markup. If the extension does not provide information about syntax inside it own tags, text will be black (default color for text). And I sure, for some extensions it can be helpful to highlight text inside their own tags. (@Niharika it can be optional since, for example, user will be able to choose theme, where text inside extensions tags is not highlighted or maybe press a button to disable/enable highlighting text inside extensions tags, I not sure that it will be required at all, since when highlighting will be added to extension tags, it will be tested on the "looking like a total mess")

@Niharika, @DannyH - My understanding of Pastakhov's current plan is that CodeMirror will provide 2 ways that extensions can customize syntax highlighting:

  • Specifying the content-type of content within a set of tags. For example, specifying that content inside <phptag> tags should be highlighted as PHP code or that content inside <ref> tags should be highlighted as WikiText code. This seems sensible and needed.
  • Adding class attributes to all tags. This allows anyone (users, wikis, extensions) to customize the highlighting of the tags. For example, a user could edit their User CSS to only highlight ref tags if they are especially interested in improving references. It would also be possible for a wiki to customize the highlighting for all users of that wiki by styling the classes in the Common.css for the wiki (although this is not a likely use case). It would also be possible for an extension to customize the tag highlighting for any particular group of users (or all users) with it's own CSS file. That doesn't mean that extensions are actually going to utilize this ability, and as Pastakhov mentioned, abuse of this could be prevented via code review. All tags will be highlighted as green by default, so there won't be any expectation or need for extensions to create their own custom tag highlighting (unlike Pastakhov's previous implementation). If we want to support the ability for users to customize their own highlighting (which seems like a legitimate and useful use case), this seems like the best way to achieve that. Unfortunately, there isn't any practical way to allow users to customize the highlighting for themselves that couldn't also be used by extensions or wiki admins to customize the highlighting for everyone.

Change 350841 had a related patch set uploaded (by Pastakhov; owner: Pastakhov):
[mediawiki/extensions/CodeMirror@master] Refactor the Integration with other extensions (v 4.0.0)

Change 350841 merged by jenkins-bot:
[mediawiki/extensions/CodeMirror@master] Refactor the Integration with other extensions (v 4.0.0)

kaldari closed this task as Resolved.May 8 2017, 10:26 PM
kaldari claimed this task.
Restricted Application added a project: Community-Tech. · View Herald TranscriptFeb 9 2018, 4:02 PM
TBolliger moved this task from Untriaged to Archive on the Community-Tech board.Feb 14 2018, 1:12 AM