Hello. I am Marijn, the author and maintainer of the CodeMirror project.

If you are here, you’ve probably heard of CodeMirror. It is an open-source code editor component, written in JavaScript, embeddable in web pages. Check out its website for details.

CodeMirror’s popularity has boomed to the point where, whenever a new startup or project is announced that somehow involves a code editor, it is a pretty safe bet that you’ll find CodeMirror powering it. Some recent examples are Collide, Light Table, and Brackets.

This is absolutely great. I love seeing people get value out of my code, and I feel that, having a robust, easy to embed code editor, the Web is a slightly better place.

I am now spending between half a day and a full day a week maintaining CodeMirror—responding to mail, fixing bugs, implementing small improvements, and reviewing pull requests. And that is perfectly all right. I’m also getting value out of CodeMirror (notoriety, free-lance gigs). But when there are bigger features or changes to be made it can be hard to justify taking several days off of paid work in order to to work on CodeMirror.

As an experiment, I’m asking the community to pay me to work on improving CodeMirror for two or more weeks.

€2000 per week is pretty random. It’s less than my regular free-lance rate, but a lot more than the €0 that I usually charge for CodeMirror work.

So what do I want to do with that time?

A better test suite

There have been several regressions and more or less obvious bugs that made it into releases in the past half year, as well as a lot of unintentional breakage between releases. Almost all of this could have been caught by simply having a more exhaustive test-suite. Writing tests is boring, time-consuming work, but regressions consume a lot of time as well, and I’ve become convinced that it is necessary to seriously push on this.

A big problem is that our test suite can’t test many of the subtle, error-prone parts of the code, because to test these these would require firing actual, browser-native events. That’s why I am looking into wiring up some Selenium-based tests in an attempt to guarantee that some tricky bugs do not come back. I’ve already written a proof-of-concept node.js shim that allows me to drive Selenium from the browser, ensuring that we won’t need too much Java in this test suite.

This should benefit all CodeMirror users.

Variable-height lines

Another thing I’ve been wanting to tackle for a while is to finally implement variable-height lines. Currently, the code assumes all lines have the same height, and the display corrupts when, for example, you display some tokens in a bigger font size.

The main obstacle to the variable-height feature is the way the gutter works—the area to the left of the code where, for example, line numbers are displayed. Coincidentally, the gutter is currently implemented in a way that makes it painful to extend with custom widgets. So as part of the variable-height implementation, I intend to reimplement the gutter in a way that separates the line-number area from the area where user code can place widgets, so that they can be independently managed and styled, and the awkward corner cases that stem from their entanglement go away.

This also opens up the road towards brave new horizons such as embedding widgets in-line and having callbacks that control the rendering of particular tokens.

And beyond

If this campaign ends up bringing in more than the target, all of the money still will be used for doing further work on CodeMirror. I have some ideas on what to work on next (the bug tracker is non-empty), but am open to suggestions. One obvious candidate is optimization. There is definitely still room for improvement there.

Thanks for reading,
Marijn