In Electron 0.37.3 the default background color has changed from white
to transparent, and as per the sub pixel anti-aliasing specification,
the layer which hosts the glyphs that need to be rendered needs to have
an opaque background.
We have also observed that upon reload everything seems to work smoothly
even without this fix: this probably points in the direction of a
regression in Electron, but in the meantime this fix should suffice to
allow us to proceed.
Rendering those line numbers in the gutter isn't useful, and it puts
unneeded pressure to the DOM. In the process of changing
`updateLineNumbersState`, we have also refactored it to stop relying on
row ranges being contiguous. This allows that code path to be:
1. Less error-prone, because we were trying to access rows that weren't
actually rendered, thus potentially throwing errors when measuring
non-contiguous screen rows that weren't visible.
2. Tighter, because we can just iterate over each screen row and ask for
its soft-wrap descriptor.
There's a distinction to make between rendered and visible rows, and we
were using the former as if it was the latter. In particular, if a tile
is visible, all its rows get rendered on screen, even though they might
not necessarily be visible by the user.
...because the only possible scenario when a logical position in a text
node cannot be found is when the requested pixel position is exactly at
the end of the node.
This fixes an annoying problem that prevented the state of marker layers
from being saved when the window was reloaded either via `Cmd+R` in
DevTools or via `Ctrl+Option+Cmd+L` in Atom.
The issue was that we were *always* scheduling `saveState` on an idle
callback: `window.onbeforeunload`, however, doesn't wait for that event
before closing the window, and thus that state was never saved in those
situations.
The solution is to use idle callbacks only during the critical code path
(i.e. on mousedown and keydown), but save it synchronously otherwise.
Saving something to IndexedDB is actually asynchronous too, but it seems
like Chrome fulfills `put` requests that get executed right during
`onbeforeunload`.
