For the past five months, Adrian and me have been hard at work on a complete rewrite of the library. It’s going to be more accessible, touchscreen-friendly, and modular. We’re announcing the current state of this work (the prototype works great, but there’s a lot to be done) at https://codemirror.net/6/, and have started a crowd funding to support the rest of the necessary efforts. You can look at the new code (some of which is definitely still rough) on Github.
Let us know what you think!
Thank you so much for your efforts waiting for version 6 to update in our site.
Regards
https://www.tutlane.com
Cursor keys do not work on the demo.
It is a bit overwhelming to think about the years of development and integrating of CodeMirror must now all be undone for this new version. You are not even going to try to tackle the horrible scroll in mobiles (by closed issue responses).
Will you continue monthly releases of CodeMirror 5 or is that done now? For those not wishing to migrate until clear direction can be seen, will you provide maintenance releases of 5 to fix browser releases?
You’re going to have to be more specific about that (browser? platform? which keys?) because they work for me.
Nothing is going to be undone—the old editor will continue to exist, and porting to a new API that supports roughly the same features is usually not terribly hard.
I have no idea what you are talking about there.
Obviously, since usable releases for the new version are a long way off, there’ll be continued new releases for the 5.x branch.
The cursor keys (arrow keys) do not work with hackers keyboard, most used coding keyboard in Android.
The horrible scroll on mobiles was concerning the issues on github which you closed right after announcement of CM 6. If you scroll on mobile the redraw is horrible. Predictive scroll is no good for mobile either. You need a scroll model built into CM that simulates momentum scrolling. Thus being able to control the drawing events. This would make CM 6 mobile ready.
Reimplementing touch scrolling is a terrible idea for other reasons (it never feels native, and tends to perform a lot worse). It might be an idea to implement a plugin that tries to do this, but for the core we believe the right thing is to stop fighting the browser and accept some flicker on quick scrolling.
Are you accepting questions about your CM6 repo?
I didn’t find instructions for building and running the tests in there so I did a little poking around. Also I didn’t know much about TypeScript or rollup before seeing your repo using them.
I found the following seems to build view/test/test_built.js but there are many options to rollup so maybe I’m missing something important.
rollup -c rollup.view-tests.config.js --format iife
Changing directory to view/test and loading some npm modules at that level then let me start a simple file server from that directory and low and beyond, a beautiful test result page appeared in a new Chrome window on my mac showing 112 or 113 tests passed.
This was your only announcement for CM6 and the git log shows you are very busy working this new version so perhaps you don’t need or want anyone running tests with browsers on a mac yet (am on OSX 10.13.6). I would open new discussions if you are interested in the Chrome investigation and then possible Safari investigations on the same OS. I hesitated even bringing this up but when all but one unit test is passing, it made me think you like to keep your unit tests passing on at least some subset of platforms while you are developing.
Hi Frank. The way I build the in-browser tests is with npm run watch-view-tests, which runs the command listed in package.json for continually rebuilding the test bundle when the source changes. You can then simply use a file:// url to go to view/test/index.html to run the tests. I do indeed usually keep them passing on Chrome and Firefox for Linux, but don’t routinely test on macOS. Opening an issue or investigating further is definitely welcome!
It would be handy if you had a :root CSS class and handled basic styling such as backgrounds and borders with var()
We’ll continue to support some browsers (IE11) without CSS variables, so we won’t use those.
What about
.SomeClass {
background-color: brown;
background-color: var(--my-brown-color);
}
It would just ignore the var, wouldn’t it?
([sigh] the good things we can’t have because … IE!)
Can your on() functions return a handle consisting of the function arguments to make it easier to use off()?
// create listener
var myEnterListener = CodeMirror.on(this.container, "keydown", function(e) {
if(e.target.classList.contains("KeyDown") && e.keyCode == 13 ) {
e.preventDefault();
tools[e.target.getAttribute("data-action")].call(tools, e);
return false;
}
});
// remove listener
CodeMirror.off.apply(null, myEnterListener);
And maybe write off() so it accepts an array as a single arg so you don’t have to use apply()?
Hello here! I use CodeMirror in our Projects like a CodePlay, Codium and another. Now CodeMirror is very slow. Performance - 0%. I listened about version 6. I hope - you create it! (Yes I’m not English)
Hi guys! Codemirror has been a lifesaver for us and we would not be able to achive any kind of success anytime soon without it - we are releasing mobile coding app.
We plan to experiment with version 6 when it’s good enough to use without plugins - we don’t need them - what we need is to deal with the https://github.com/codemirror/CodeMirror/issues/3654. Do you know when could first stable plugin-less version be ready?
Hi Adam, I’m trying not to make any concrete promises about release dates yet since those tend to only cause disappointment—the plan is to have some kind of usable release (not necessarily an API-stable one) in 2019, but that’s all I can say at this point. And, of course, a new codebase will have new issues, so you’ll have to be cautious in how quickly you adopt it.
I think its a mistake not to use css vars , ie11 is < 3% , if a consumer of cm wants to support that , they can just continue to use v5
The demo looks great ! I played around it a bit and found that when pressing tab key, it does not indent but focuses out of the editing. As I read that this version is very mobile focused, is this something you are going to take care of ?
This is probably going to be the default behavior—it’s really awkward for non mouse users (such as blind people) to escape a control that captures tab, so it’s an accessibility issue. You can, of course, define your own key bindings, and maybe we’ll find a reasonable way to finesse it and have both our tab key and an easily discoverable way to escape the editor, but I haven’t found a good approach for that yet.
For inspiration, Jupyter does auto-indent only at the beginning of the line, auto-complete if inside the line. So auto-complete or focus change depending on the position inside the line might be worth a try.
I’m very excited about CodeMirror 6 after using ProseMirror. My current editor choice is monaco for both code and markdown, but I’m replacing the markdown editor with ProseMirror, and I really want to replace the code editor with CodeMirror. I wonder if now is a good time to do that? Is it stable?