Now you either recreate things yourself or offload the consistency patching to a framework to (hopefully) correctly handle.
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!
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 glad to see you’re focusing on accessibility!
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
It just shows many contributors but looking at code commits and general activity (maintainers) in issues only Alexandru Dima comes out.
I have no doubt that if those parties get more involved in CodeMirror, things could move very fast.
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 .)
(donated, of course)
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 :)
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.
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?
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.
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!