Now that ScreenLines don't contain the bufferRows property, which was
essential to the functioning of the LineMap, they're just containers
for tokens. Since they're stored in the TokenizedBuffer in a form that
doesn't necessarily match what ends up on screen, it makes more sense
to call them tokenized lines. A tokenized line is a screen line if it's
in the `.screenLines` array of the DisplayBuffer, but "screenness" is
not an inherent property, so it shouldn't be in the name of the class.
Creating a fold in one pane now has no effect on an edit session
for the same buffer in another pane. Before they were polluting each
other by sharing the same fold markers.
When creating a display buffer for buffers that already have fold
markers, which we'll eventually do on refresh, basing folds on
full-blown display buffer markers is a problem because we end up
creating display buffer markers during construction of the line map.
When we create a display buffer marker it memoizes its screen positions,
but since the line map isn't built yet we have nothing to translate
against. Basically, since the line map depends on folds, folds can't
depend on the line map. Luckily, they don't need to. Buffer markers
work just fine.
Still a couple of specs failing on this for changes that straddle the
start / end of a fold. We need a new marker invalidation strategy for
these cases.
Instead of marker-added and marker-removed events which are emitted
when markers are created/invalidated/revalidated/destroyed, we now
just have marker-created events that are triggered *only* when markers
are created for the first time. The marker itself emits a 'destroyed'
event when it is destroyed. The marker already notifies observers when
its validation status changes, so that's covered.
This is part of an effort to disentangle LanguageMode, DisplayBuffer,
and TokenizedBuffer. It should be easy to create a DisplayBuffer
without creating an EditSession… let's get the dependencies flowing
in a single direction.
DisplayBuffer should just focus on providing basic support for folding.
Scanning the structure of the code, looking at scopes, etc is more the
domain of the LanguageMode object.
This saves the state of the rendered lines, the display buffer, the
tokenized buffer, and the buffer to a file. If a problem arises with
rendering, hopefully we can use it to diagnose in which layer things
went awry.
