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?
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?
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!
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?
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?
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
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.
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.
I welcome competition in this space but two guys competing with Microsoft seems like impossible to win. Hopefully they get the funding and we can see what they can build
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].)
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.
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 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.
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.
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.
> 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.
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.
[+] [-] marijn|7 years ago|reply
[+] [-] tobr|7 years ago|reply
[1] https://codemirror.net/6/design.html
[+] [-] tnolet|7 years ago|reply
[+] [-] jazzyjackson|7 years ago|reply
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!
[+] [-] brainkim|7 years ago|reply
I’m glad to see you’re focusing on accessibility!
[+] [-] louisstow|7 years ago|reply
[+] [-] skybrian|7 years ago|reply
[+] [-] nkkollaw|7 years ago|reply
[+] [-] tokyodude|7 years ago|reply
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
[+] [-] marijn|7 years ago|reply
[+] [-] adrianheine|7 years ago|reply
[+] [-] spankalee|7 years ago|reply
[+] [-] yesimahuman|7 years ago|reply
[+] [-] Cthulhu_|7 years ago|reply
[+] [-] draw_down|7 years ago|reply
[deleted]
[+] [-] msoad|7 years ago|reply
[+] [-] keithwhor|7 years ago|reply
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
[+] [-] undershirt|7 years ago|reply
(donated, of course)
[+] [-] marijn|7 years ago|reply
[+] [-] ddoolin|7 years ago|reply
[+] [-] sehugg|7 years ago|reply
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 :)
[+] [-] Narretz|7 years ago|reply
[+] [-] adrianheine|7 years ago|reply
[+] [-] amelius|7 years ago|reply
https://google.github.io/xi-editor/docs.html
[+] [-] Flimm|7 years ago|reply
[+] [-] adrianheine|7 years ago|reply
[+] [-] wirthjason|7 years ago|reply
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.
[+] [-] bealuga|7 years ago|reply
[+] [-] rglover|7 years ago|reply
[+] [-] leeoniya|7 years ago|reply
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?
[+] [-] marijn|7 years ago|reply
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.
[+] [-] le-mark|7 years ago|reply
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!
[+] [-] adrianheine|7 years ago|reply
[+] [-] GoToRO|7 years ago|reply
[+] [-] marijn|7 years ago|reply
[+] [-] pandeiro|7 years ago|reply
[+] [-] tequila_shot|7 years ago|reply
[+] [-] adrianheine|7 years ago|reply
[+] [-] nobody271|7 years ago|reply
[+] [-] dominikoledzki|7 years ago|reply