The goal of this project is to experiment a little with syntax aware editing
and basic IDE functionality.

A bare bones text editor is already in a working state:

- Rope data structure for efficiency. (see below)
- UTF-8 encoding/decoding.
- Basic windowing and OpenGL access using GLFW library
- Text rendering using FreeType library.

Now I want to include a parser for a simple programming language that has a
valid parse tree for any text that is buffered in the editor.

That means that the parser needs to insert "INVALID" nodes in the AST where it
failed to parse the input, and it must try to recover as soon as possible to a
known state, to avoid having the rest of the input subsumed under an INVALID
node.

The syntax of the programming language must be explicitly designed to support
reliable and early recovery.

Most importantly, I want to make everything such that the AST is updated
incrementally as the buffer is edited. I don't want to re-parse the whole
buffer on every little change. And I don't want to re-create all defined
objects, identifiers, checked types, and so on, that weren't changed by the
edit in the first place.

ROPE DATASTRUCTURE
==================

This project contains a rope implementation based on a Red-black tree, where
each node of the tree holds up to 8192 bytes. Thanks to that implementation,
most text editing operations, like navigating or inserting/deleting small
chunks of text, take only a few microseconds. Even in a test that I did with a
huge buffer (loaded from a 1.8G text file) most operations took < 20us on my
computer.

In other words, there is no noticeable latency from the internal data
structures. That should enable a very good user experience, even for very
complex operations.

Since the rope data structure has no idea about the shape of the data (binary
files, huge files, files with extremely long lines, etc.), these figures apply
for any kind of text file.

When a buffer is loaded from a file, the memory usage will be only slightly
larger (about 5%) than the text itself. In pathological cases (deleting just
the right spans after loading a large file), I think that overhead could go up
to about 50%.  But these cases are probably not practically relevant, and we
could still figure out an optimization.