I don't think that this component was really carrying its weight. Its
render function basically passed through directly to other components
that updated between renders, but didn't contain any content on its
own that actually changed after the first render.
React components seem to carry overhead, so I want every component we
use to count. Also, I'm considering circumventing some of React's
standard update logic for performance reasons, and making the structure
more shallow will help with that.
If a mousewheel event is triggered when the editor can't be scrolled,
we still want to clear the mouseWheelScreenRow. This is typically done
when we stop scrolling, but if we never start scrolling it will never
happen. This commit adds another timeout to cover that case.
Fixes#2429, #2443
Otherwise, it's possible to duplicate lines. If a line is in the
rendered row range and it's not in the set of lines returned by the
editor, we should remove it no matter what. Line preservation is only
intended for lines that are out of view.
When we handle a mousewheel event targeting a line or line number, we
assign the mousewheelScreenRow to prevent the removal of the target
node, which interferes with velocity scrolling.
However, the ::mousewheelScreenRow is only cleared 100ms after we stop
scrolling vertically. This means that if we're only scrolling
horizontally, it's never cleared. This causes the line node associated
with this screen row to hang around longer until the mousewheel screen
row is cleared again, which is not what we want.
This commit only assigns the ::mousewheelScreenRow when scrolling
vertically, so we can be sure it will be cleared.
The editor's scroll view is getting autoscrolled when the editor is
focused, so we won't position the hidden input until after the editor
is focused, and will always return it to 0,0 when the editor is blurred.
CSS has a line-height property with values like '1.3', but we also have
a measured pixel value for line height. It's important to keep these
separate conceptually.
