Would be interested in a short overview of contentEditable in 2018. Until very recently the consesus was that it's completely broken, but I understand from the design document[1] that it's good enough for you to build on now? Does it “just work” or is it only a slightly smaller mess than before?

[1] https://codemirror.net/6/design.html

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.

how do you plan to handle multiple cursors (eg: simultaneous-edit & collab), vertical / column selections, and multiple disjoint selections?

The DOM selection corresponds to the primary selection, the others are drawn using CSS spans. This means you only get touchscreen-style handles on the primary one, but I think that's acceptable.

By the way, how do we select multiple lines in chrome? I can do it in firefox in the "old" CodeMirror, but not in my chromebook.

Mouse drag or shift up/down works for me? Or what kind of selecting are you trying to do? (Or, if this was about multiple _cursors_, those are only half-implemented, and not exposed through the UI yet.)

Interesting! I actually wrote https://github.com/SjonHortensius/LRTEditor to replace CM, but the many subtle browser bugs eventually forced me to abandon it. Do you expect to use shims and possibly let browser-vendors fix bugs/inconsistencies you find?

We're not really using shims, just targeting the lowest-common-denominator contentEditable behavior that we can count on, and implementing anything else ourselves.

‘Because you can't really rely on the browser to get them right‘- welcome to the state of the web today- inconsistencies everywhere and no fix in sight :(

Now you either recreate things yourself or offload the consistency patching to a framework to (hopefully) correctly handle.

Well, this has been the case with the web for a while. See: jQuery.

Hi Marijn, I rely on CodeMirror for a SaaS I run (from Berlin). I will donate what I can. Just one question and please don’t take this the wrong way, but can you provide an insight into how you got to 80k as the target amount?

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.

Hi Marjin, I've been extremely impressed working with Codemirror. The event API is really easy to work with and I love the ease of switching syntax modes and color schemes.

I'm building a product around CodeMirror and as a vimmer, I intend to carry Vim mode with me.

Will CodeMirror6 implement vim mode in a similar fashion?

I'll send you some coin either way, thanks again for developing such a great project!

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

I’m currently in the process of writing a codemirror mode for a language I’m working on, is the way codemirror modes are written/used gonna change substantially? Should I hold off on this work?

I’m glad to see you’re focusing on accessibility!

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.

Hi Marijn. Big fan of ProseMirror. Would you look at building CodeMirror on top of (or at least sharing code with) ProseMirror so both projects can benefit from the effort?

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?

Have a look at https://prosemirror.net/examples/codemirror/ :)

I'm curious if you learned anything from studying monoco-editor from VS Code? Do they use a different approach?

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

Love the software. Awesome job!

Are you planning to make it easy to add autocomplete support for languages like TypeScript?

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

Why typescript? wouldn't that choice reduce the number people that can contribute?

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.