I'm happy to announce that with version 0.8.0 the CodeMirror
6 project is entering its beta phase,
and you're very much invited to start trying it out and poking at it.

Roughly, this ���beta��� status means:

I actually like the current programming interface. Apart from the
move from a mono-package to a group of separate packages (removing
the next/ in the package names), no significant breaking changes
are planned. There might still be breaking changes in peripheral
parts of the interface, when real-world experience shows the
current interface to be problematic, but these should be of the
type where a quick scan of the release notes and some grepping
through your code are enough to adapt to them.

The system is no longer a hopeless unfinished mess. In fact, it
seems to work pretty well. Which isn't to say it won't break in
your use case, of course, since it has seen little practical use
yet and you're likely to be the first to do some specific thing
with it.

I've put together enough
documentation for people who don't
want to read source code to be able to figure out how the system
works. Some of those docs are still rough (issue
reports welcome),
but they should be usable.

You can read the change
log
if you want to see, in some detail, what I've been up to in the past
months.

The
retrospective
for the Xi editor project
has inspired me to also spend some time thinking about this project's
goals, and how they developed.

In the initial announcement, we emphasized these goals:

Accessiblity (especially screen reader usability)

Mobile support

Native Unicode/bidirectional text support

Modularity

Performance (especially avoiding performance cliffs for huge files
or long lines)

Well-designed, TypeScript-friendly programming interface

Most of these we followed through on pretty much as planned. The
exception to this is the bidirectional text and Unicode support���that
did get implemented, but not by leaning on native behavior.

The reasons for this are:

It is often extremely hard or awkward for scripts to interact with
the native behavior. Though browsers compute an odering for
bidirectional text, scripts cannot access this ordering. Though
browsers (sort of) have advanced cursor motion logic, the only way
to get at this is to focus an element, put the selection in there,
use
Selection.modify
to move it, and then see where it went.

Often the native behavior just isn't very good. Chrome, after we
started this project, seems to have given
up
on proper visual cursor motion. When there are non-text elements in
the document, cursor motion is inconsistent between browsers and
often just broken.

Even when the native behavior isn't downright buggy, it might not
be what we want for a code editor. Selecting by word should take
criteria specific to the programming language into account, for
example.

Thus, the project has ended up with its own implementation of Unicode
segmentation, bidirectional text ordering, and, on top of that, cursor
motion. The original vision was that we could avoid this, but that
didn't turn out to be realistic. On the bright side, not depending on
native behavior makes the library a lot less susceptible to all the
bugs and inconsistencies in those native implementations.

Of the remaining points, modularity is probably the one that I
underestimated the most. Just organizing the library core as a number
of separate modules was already a somewhat subtle exercise, but the
real difficulty lies in making sure 3rd party code
composes
smoothly. The extension system went through four or five rewrites, and
drove me to desperation at times, but I'm happy with what we landed
on.

Avoiding performance cliffs has also required a lot of discipline to
make sure complexity is only linear to document or line length when it
absolutely needs to be, as well as careful API design to avoid making
the slow approach the easiest or most obvious one. But I feel the
vision has been realized well.

Having lived with a latent anxiety about whether I'd be able to
deliver this project's promises for over two years now, I think I'm
about to start actually believing I can. That's a relief.

The main thing you'll probably notice, when trying to integrate the
library, is that a lot of languages don't have any support yet. This
is the next thing on my roadmap. I'll implement proper support for
some more major languages, and port most of the old CodeMirror 5 modes
so that they can run in CodeMirror 6 (though, apart from some
languages that are absolutely unparseable in a context-free way, the
vision is to move to Lezer grammars
for all important languages).

Next up would be the mostly-drop-in compatibility wrapper to the
CodeMirror 5 interface that I've been talking about.

(But right now, we have summer holiday here, and the pace of work will
be slow to nonexistant during the coming weeks.)