Oh hi, I'm Marijn, one of the maintainers. It doesn't look like this submission is going anywhere, but I'll keep an eye on the comments and respond to questions.

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!

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.

I have to ask what is probably a dumb question.

Why? I used CodeMirror on three projects. It was great. Now I use Monaco aka Visual Studio Code. What would CodeMirror offer ? With Monaco I get all the lastest feature of VSCode . Current versions of Monaco include Intellisense etc..

I'm honestly curious both what CodeMirror will offer and why even try to compete. Though I'm guessing the answer to the first question answers the second

CodeMirror aims to be slimmer, and less of a cut-off piece of vs code. I also think our API is more well designed and expressive. And, as Adrian mentioned below, though he got downvoted, CodeMirror works on phones

The fact that it works on mobile is the biggest advantage imho. We use it for that reason.

For one thing, monaco doesn't even try to work on mobile browsers.

CodeMirror's existing code base is really clean and easy to understand, and it loads as native JS modules. It's good to have multiple projects in a similar area, and I'm excited about this rewrite as an embedder.

Monaco isn't exactly the easiest editor to extend. For those wanting to do custom editor functionality, it still feels like there's a ton of room for other implementations.

yeah Monaco is a code editor. CoreMirror can easily and nicely function as an "editor" in general. I used it in a big project for a specific kind of markdown editing experience. I checked out Monaco at the time and CodeMirror and CodeMirror was WAY easier to setup and integrate into my app.

I've evaluated both CodeMirror and Monaco in a project that had to show a dozen or so small code editors (highlighting, intellisense) on the screen; CodeMirror was a lot more lightweight and faster, whereas Monaco is a lot heavier and more aimed at having just a single instance per page.

They are not putting _that_ much energy into Monaco, and these are not terribly huge systems. Also, I've been doing this for ten years, so that helps, in terms of experience.

I wonder how one Finnish engineer could possibly compete with all Microsoft's many engineers in the OS space.

I'd wager, by cloning another successful OS. Also, all Microsoft engineers didn't work exclusively on the kernel.

Monaco is maintained by a single guy from my understanding: https://github.com/Microsoft/monaco-editor/graphs/contributo...

It just shows many contributors but looking at code commits and general activity (maintainers) in issues only Alexandru Dima comes out.

That's not where the monaco code lives. That's just for documentation. I think the actual code lives in the vscode repo

It is possible that less than 2 people at Microsoft are working on Monaco full time but just getting passive improvements over time. Never underestimate 2 smart dedicated engineers.

You say competing with Microsoft, but, CodeMirror is being used as the editor in Chrome, Firefox and Safari's dev tools, as well as Light Table, Brackets and Bitbucket - according to the blurb on their own home page.

I have no doubt that if those parties get more involved in CodeMirror, things could move very fast.

This is awesome! We were thinking about using CodeMirror for our in-browser editor, code.xyz [1] but wrote our own rendering engine from scratch in order to make sure we could distribute a lightweight package. If CodeMirror 6 had existed at the time we may have used it. We managed to get the total size to a fraction of that of CodeMirror.

If the community is interested we can definitely talk about open sourcing our editor, or if the CM team is interested in how we implemented some aspects I'm not opposed to sharing details. I can be reached at keith [at] stdlib [dot] com. We're a team of three engineers in SF, I'm responsible for the majority of the rendering engine implementation. :)

(If anybody is interested in my previous contributions to open source, they're available on my GitHub [2].)

[1] https://code.xyz

[2] https://github.com/keithwhor

I didn't know what beautiful JS code looked like until I started reading CodeMirror while debugging an issue. After reading through Atom's code, I was really surprised how simple CodeMirror's code was—with minimal abstractions and flat functions.

(donated, of course)

Thanks! It's going to get a little more abstract in v6 (but only where the abstractions carry their weight).

i'm sure the abstractions will increase out of necessity. it was just nice for once to warily peek into the code of a great product and see a single, well organized ~9k line file of small functions that I could follow with relative ease. best wishes on the new version!

Just donated what I can for now. I've used CM in a number of projects over the years and it's quite enjoyable once you get used to it, the feature set is comparatively large, and the defaults are quite good. If you're willing to go the extra mile, the customization runs deep. Good luck on v6 guys, looking forward to it.

We use CodeMirror for our 8-bit retrodev IDE, and have been pretty happy with it: http://8bitworkshop.com/v3.1.0/?=&file=examples%2Fbrickgame&...

We haven't even scratched the surface with customization beyond adding some more editing modes (fortunately a Z80 mode is already part of the release!) and doing custom gutters and line widgets.

There haven't been very many surprises, notably a performance issue with forced reflow when gutters are overwritten (solution: don't do that) and some vertical div sizing problems, which shows how difficult this kind of project is to do right. Performance has always been stellar, though, even on an underpowered Chromebook.

+1 to Typescript, we've also been converting our IDE over to it :)

How will this affect ProseMirror development? Do you see ProseMirror at a point where it can be considered stable enough that it doesn't need a lot of attention?

Yes, ProseMirror is quite stable and it is well-used. Marijn released version 1.0 nearly a year ago and since then we made some improvements, but the interface seems good enough that we didn't even discuss making a breaking change in a component as far as I know. There's not too much maintenance work necessary either, since bug reports are usually pretty good and far fewer than for example with CodeMirror. I think how happy we are with ProseMirror and maintaining it is a major motivation for making these huge changes with CodeMirror, too.

By the way, the Xi-Editor of Raph Levien (Google) has some architectural notes, which could be useful.

https://google.github.io/xi-editor/docs.html

Indeed, I'm aware of those and they are great.

Thank you for considering the needs of people who speak non-LTR languages, like Arabic. I'm excited that bidirectional text support is in the roadmap!

That's great to hear! CodeMirror 5 has complex code for supporting bidirectional documents, but it's not perfect and lot of work. We hope to let the browser do most of this work for us in the new architecture.

Thanks for your work Marijn! I've never developed with CodeMirror before but have used it in IPython notebooks.

I'm sure there are multiple ways open source projects can raise money but one idea I'm fond of is a paid "course". Basically this amounts to a couple hour tutorial. It helps gain users and present a deeper insight into the project while generating income.

Ah I loved code mirror! I ended up using it in one of my projects called picoshell here which was an in-browser code editor. https://www.youtube.com/watch?v=6ubEwT6igZQ

Just happily backed this :) CodeMirror helped me TONS a few years back while writing a custom CMS for editorial work. Best of luck, Marijn—thanks for everything you've done so far.

one thing i immediately noticed is that the line gutter no longer lags during hz scrolling on my phone :)

i'll definitely be pitching in.

something that's always bugged me about the current v5 syntaxes is that colors (and token types) are not consistent across languages.

ideally i would prefer to have a local var, a regex, a builtin colored the same in all languages. not just as a result of carefully tweaked css but because of token/css class uniformity.

any plans to address this in v6?

> one thing that's always bugged me about the current v5 syntaxes is that colors (and token types) are not consistent across languages.

Yeah, me too. We're planning to move to something more close to what other editors (ST, Code) do and work with hierarchical token types (variable.local, variable.type.definition) instead of having a set of disjoint types. There remains the problem of some modes simply supporting more features (i.e. if one mode doesn't distinguish definitions from uses and another does, the colors will, depending on the theme, still look different), but it should help unify things quite a bit more.

Great project, I used it for an online code editor a couple of years ago.

My question is; what's the status of mobile/touch support? It used to be barely usable on touch devices. How is touch support vs Atom? I haven't followed this in years so apologies!

Improving mobile, touch and screen-reader support are from a user perspective the main reasons we are doing this in the first place. We are expecting to support most of the input behavior such platforms provide.

Can it edit the files on a server directly or you have to do that part yourself? Or are there any projects that I could self-host and let me edit the files on a server folder? Thanks.

You have to do that yourself—this is only the editor component. There's things like https://icecoder.net/ that provide a more web-ide like thing on top of CodeMirror, but I don't know them intimately so I don't know which one to recommend.

When the demo embedded in a fundraising pitch supports Emacs keybindings, I donate. Simple as that.

The page doesn't tell me anything on how to contribute code.

Except for small drive-by contributions (see GitHub repo) the project is not in a state were we can really integrate other people in our process, and there will be pretty substantial changes to interfaces. Looking at ProseMirror, contributions will probably mostly include separate modules and not so much work on the actual core (which is pretty stable). This is especially true for CodeMirror where there will be a lot of modes, addons, themes and keybindings, which we are not planning on maintaining as part of the core project.

old jQuery UI style, please:

    window.codeMirror("#myCodeMirrorDiv");

    window.codeMirror("#myCodeMirrorDiv", {
        theme: window.codeMirror.themes.dusk,
        maxColumns: 120,
        lineNumbers: true
    });

btw why would you ever put yourself through such a thing?