This entailed quite a few changes to dial in scrollbars. The scrollbars
are now adjusted in size to account for the width of the opposite
scrollbar. If the width or height are not explicitly constrained and we
are scrollable in the opposite direction that is constrained, we account
for the width of the opposite scrollbar in assigning a natural height
or width based on the content.
We set overflow to hidden in the opposite scroll direction only if we
can't actually scroll in that direction, causing the white square where
neither scrollbar overlaps to appear at the lower right corner.
This assumes the scrollbar is 15px high, which is incorrect when using
overlay scrollbars or when the scrollbar is styled to have a different
height. We'll need to measure it in a subsequent commit.
This commit breaks the initial render of the editor component into two
stages.
The first stage just renders the shell of the editor so the height,
width, line height, and default character width can be measured. Nothing
that depends on these values is rendered on the first render pass.
Once the editor component is mounted, all these values are measured and
we force another update, which fills in the lines, line numbers,
selections, etc.
We also refrain from assigning an explicit height and width on the
model if these values aren't explicitly styled in the DOM, and just
assume the editor will stretch to accommodate its contents.
This preserves the original behavior of the editor model with respect
to scroll position and autoscroll unless it's being used by the react
component, which flips the ::manageScrollPosition flag to true.
This bakes character width tracking into display buffer directly, which
moves us toward a world where all rendering decisions can be made in the
model to strictly control DOM reads.
Fixes#1576
When splicing regions into the row map, we always express the starting
buffer row, then the number of buffer rows covered by the regions we're
inserting. When we're inserting regions representing folds, they always
extend to the end of a fold, so we need to ensure the endBufferRow also
extends to the end of the fold.
For example, say rows [5…10] are folded, and we handle a replacement of
rows [5…8]. We will still insert a region for the fold covering 1 screen
row and 5 buffer rows, so we need to update the endBufferRow to extend
to the end of the fold as well (10).
