When we have an unexpected display-buffer or tokenized-buffer state,
we can include the change counts to make sure that every change to the
buffer has been processed by display-buffer and tokenized-buffer. If
they haven’t, there’s something wrong with our event ordering. If they
have, there’s a logic error somewhere else.
This is pretty hacky. If we want to compute the true longest line, we’ll
need to process every line, which is what large file mode is designed
to avoid. So now whenever the display buffer returns a line, it has
the potential to update the longest line.
This is a bit weird because retrieving a line now has a side effect.
It’s even more weird because the longest line will actually be wrong for
the initial state updates in the TextEditorPresenter. But as soon as
the user interacts in any way the dimensions are recomputed, so it works
for now.
A better approach may be to set a visible region on the display buffer.
But I’d like to keep this low-touch until we have a chance to revisit
the design of DisplayBuffer in a bigger way.
* Don’t tokenize
* Don’t build metadata to support folds and soft wraps
Remaining issues:
* Max line length is hard coded
* Foldable indicators should be disabled
* Folding via API should be disallowed
Previously, instantiating a TextEditor would always compute compute
screen lines twice: once when the DisplayBuffer was instantiated,
and once when the 'invisibles' property was set on the DisplayBuffer.
Currently screenPositionForPixelPosition special cases pixel positions
below the last row so that the column position is always set to the
last column of the last line, even if the pixel 'x' position is less
then that column.
This patch special cases picks above the first row so that the text
column position will be in the first column even if the pixel 'x'
position is greater then that column.
At a higher level, this patch fixes the problem where you can’t select
to the start of a text field by just clicking and dragging up. Instead
you have to click and drag back (x axis) beyond the start of the text
field.
This fixes#4596, where the calculation returned a wrong range.
* 📝 State clearly that we'll return a closed interval in docs
* ✅ Write tests to ensure a correct behavior
