For some reason, having flex-flow column on the pane item views
container was forcing the entire view to be repainted on cursor
movement and line edits. Allowing the container to flow row-wise and
setting the min-height to 0 instead of min-content-height achieves
the same layout effect without the huge repaint cost. Flexbox is a
fragile bitch.
If we remove a large number of screen lines when we are scrolled down,
the current @firstRenderedScreenRow may end up being larger than the
number of screen rows we now have. Setting renderFrom to the
@firstRenderedScreenRow in this case was causing the renderFrom to be
larger than the renderTo, which was causing problems downstream with
the new mapping code.
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.
Previously, we used bufferRows to determine how many buffer rows were
spanned by the screen line in the event it was folded. Now that we have
RowMap, screen lines don't need to serve this purpose. We still need
to know if a screen line is wrapped, which we solve via setting the
lineEnd property to null for a soft-wrapped screen line.
When we're creating folds that contain other folds, we'll need the
region based on the new fold's row mapping to overwrite the regions
from the old folds. This commit ensures that the new region cleanly
slots in, replacing any regions it completely contains and splitting
regions that it only partially overlaps.
If there are multiple mappings following the start row of the delta
that span fewer screen rows than the delta, we collapse mappings to 0
screen rows until we have removed the number of rows specified by the
delta.
Expanding positive deltas expands the first mapping following the
start row as it did previously.
Inserting a mapping should never change the position of any existing
mappings on screen or in the buffer. It's simply a statement about a
range of rows in the buffer mapping to a range of existing rows on
screen, but shouldn't add or remove any rows. Adding and removing rows
on screen or in the buffer is the job of the applyBufferDelta and
applyScreenDelta methods.
