Update Codemirror to version 6

[goanpeca]

Problem

Currently codemirror (5.x) presents some performance and accessibility issues which have been addressed in the new version CodeMirror Next ( https://codemirror.net/6/)

Proposed Solution

Update to use the new version

Additional context

This version is backwards incompatible, so this would go into JLab 4.x

Performance

@echarles worked on some performance benchmarks:

CodeMirror Next brings performance boost but is backwards incompatible (operation + contain workarounds bring the best improvement with stable version)

Luminio resize event seems to be the cause of the performance degradation (disabling that event brings back the jlab cells in lumino panel in-pair with plain codemirrors).

[goanpeca]

Pinging @mlucool

[jtpio]

cc @dmonad

[isabela-pf]

This was brought up in the JupyterLab accessibility meeting on June 2 and the JupyterLab team meeting on June 9. There weren't any community members who spoke against this at either meeting, though it should be noted neither meeting represents all active members of the JupyterLab community.

If you think I missed something, please add it to this issue!

To summarize the discussion:

Accessibility reasons for CM6

• The code editor is a big part of JupyterLab and holds several WCAG violations as of now. Usability with screen readers #4878, Accessibility Issues Needing Addressing for WCAG 2.1 compliance (As of Version 2.2.6) #9399
• It's difficult to address this in CM5 because it is working against how the editor is built. It also seems like a waste of effort when there are editors (like CM6) being developed for accessibility.
• CM6 is not the only code editor made with accessibility in mind. JupyterLab is more closely tied to CM5 than its other editor options, though, so it might be less disruptive for the whole codebase to stick with CodeMirror.

RTC reasons for CM6

(Paraphrased from @dmonad)

• Implementing desired RTC features like commenting and "showing the differences" will take effort and will probably only work on one editor. Since JupyterLab is currently more coupled with CM5, it makes sense to continue with CodeMirror.
• It would be better to think ahead and implement this for CM6 than do the work for CM5 and then have to update it in less than a year (for example).

How should this be done?

• As mentioned above, JupyterLab currently supports multiple editors. Should it continue to do so when this can make implementation and maintenance more difficult and may block progress on major priorities like RTC and accessibility? To me, it sounded like people were open to having a single editor in JupyterLab, though this is a big change and probably needs to be discussed somewhere else too.

Is it the right time?

• Is CM6 stable? It currently says "The project is in the beta phase—there's a stable interface, but small breaking changes might still happen. It is being used in production in a few mid-size systems, but is not as battle-tested as the old version."
• This is a major change and needs to be done in a major release. If we don't want to harm or block RTC or accessibility, now is probably the right time.

This sounds like a go-ahead to me (correct me if I'm wrong). In case it needs to be said, I am personally in favor of this update even though I don't have the skill to do the work.

[jasongrout]

@isabela-pf - thank you so much for summarizing the discussion. I think a good set of next steps would be:

1. mention it again in the team meeting next week to call again for any objections
2. (optional?) it would be great to reach out to Marijn to see if there is any sort of timeline or intution for when CM6 might be declared stable.
3. Someone putting in a PR to remove the abstract editor interface and upgrade to codemirror 6
4. Review, merge if appropriate, and release an alpha so people can test their extensions.

Likely this will break many extensions, but since our abstract editor interface closely tracked the codemirror api, hopefully it won't be too hard to update existing extensions.

[krassowski]

It seems that some of the default modes got simplified: codemirror/dev#284 compared to v5.

[jtpio]

cc @JohanMabille who has been looking into that recently

[JohanMabille]

Hi folks,

I have started hacking aroud this, now I am going to do something more serious. I will open a draft PR for the upgrade to codemirror 6 when I have something acceptable. I planned to drop the codeeditor abstraction in a dedicated PR, once the migration is done, what do you think?

[manfromjupyter]

@JohanMabille I just wanted to say something in case you didn't see the thumbs up. I know a ton of people super excited for this. Have a couple lined up to test it for accessibility once you get it to that point too. Please know there is great support for this. Please feel free to @ (at) me in the merge request when you get there and I'll test it and ping other people to test it.

[jasongrout]

I have started hacking aroud this, now I am going to do something more serious. I will open a draft PR for the upgrade to codemirror 6 when I have something acceptable.

FYI, @JohanMabille opened a draft PR to explore moving to CodeMirror 6 at #11638

[williamstein]

There's an interesting new blog post comparing CodeMirror 6 to Ace and Monaco here:

https://blog.replit.com/code-editors#head-to-head

[jasongrout]

Just consolidating info for future reference:

• Replit had two interesting articles on their reasons for choosing CM6: https://blog.replit.com/code-editors and later https://blog.replit.com/codemirror
• William posted the first blog post above on HN, which generated some interesting discussion, including more comments from the replit folks: https://news.ycombinator.com/item?id=30673759. In particular:

Author here: We might release our LSP implementation for CodeMirror some time this year.
The LSP integration for Monaco is lackluster, it works, but isn't great. We thought LSP would work perfectly on Monaco only to find out that the Monaco APIs are very different from LSP APIs or even VSCode APIs. The 3rd party package out there is good, but you need a bunch of monkey-patching to make it work in an "IDE" environment.

and on accessibility:

CodeMirror 6 appears to be more accessible. However it still only shows one line at a time. So that's still worse than Monaco. Monaco can show one or two hundred lines at a time. So with CodeMirror 6 I still would have to read text line by line without any way to skip a function for example, which is unnecesarily tedious.

[joelostblom]

Just a note that vim-mode is not available in Code Mirror 6 by default, but the people at replit has made a CM6 wrapper for the vim-mode from CM5.