It's underspecified and very hard to implement (and hence, not implemented all that well), but if you know the pitfalls (only some DOM/style structures are well supported, cursors vanish in some circumstances, etc) and avoid them, and implement non-trivial editing commands yourself (because you can't really rely on the browser to get them right), contentEditable is a functional way to represent editable content in the browser.

It's roughly what the two of us need (in addition to regular donations and support contracts) to be able to work on this for one year. We expect a year to be enough time for stabilizing the core and porting some essential plugins.

> Will CodeMirror6 implement vim mode in a similar fashion?

This hasn't been decided yet—I'm aware how much people appreciate the vim bindings, but they are _huge_ (as big as the current core) and written by someone else. I'll probably take a stab at porting them when the new API is stable, and give up when it turns out to be too messy. On the bright side, they have a lot of tests, which helps with making sure I don't break them. But they _are_ still looking for a new maintainer, and even if I do port them, I'm not taking over maintenance.

Modes implemented against the current interface will be supported by a plugin. We are definitely planning on providing a better interface for highlighting eventually, but that will take some time.

There's a lot of architectural influence on the new CodeMirror from our ProseMirror work, but the actual systems are different enough that code sharing didn't really work (or, at least, would add enough levels of extra indirection and complexity to the reused code that it's not worth it—code size is a significant cost in JS components)

This makes me wonder. What would happen if you'd embed a piece of code inside a text document? Would you need to embed a CodeMirror instance inside a ProseMirror instance?

I did study Monaco, but we're using a very different approach (Monaco resembles the current CodeMirror more), because what they do in almost impossible to make work on mobile. When it comes to accessibility, they do a great job, and I'm planning to take more inspiration from their code as I work on things like autocompletion

It should not be hard to do this as a plugin, but the core maintainers are unlikely to work on it.

It provides significant advantages when it comes to noticing bugs and including types (also for docs) in the code from the start. I feel that TypeScript is widely enough known at this point (and close enough to JavaScript to figure it out quickly) to not be too much of a barrier.

On the contrary, it makes it easier for people to contribute as their code is more likely to actually work.

Is the programming language really the important thing that limits who can contribute? People who are skilled in writing text editors and development tools can probably adapt to TypeScript without any issue.

TypeScript is really just JavaScript with intuitive type checking.