▲ 342 points
back
73 comments
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?
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.
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?
I'm curious if you learned anything from studying monoco-editor from VS Code? Do they use a different approach?
Love the software. Awesome job!
Are you planning to make it easy to add autocomplete support for languages like TypeScript?
Why typescript? wouldn't that choice reduce the number people that can contribute?
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
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.
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].)
[1] https://code.xyz
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).
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.
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
});