In 444c18be34, I stopped polling the DOM
when an update was pending to prevent delay of the next animation frame.
Unfortunately, we rely on synchronously polling the DOM when an editor
view is attached to perform the initial measurement of the default char
width, which is required to position the wrap guide.
In componentWillMount, observing the config was requesting an update,
causing us to skip this synchronous update at attachment time and
position the wrap guide wrong.
This prevents update requests that occur before mount from pausing the
polling that we perform on attachment, restoring correct function to the
wrap guide.
In Chrome 31, setImmediate was yielding better behavior. But now Chrome
35 seems to behave more smoothly when we use requestAnimationFrame, and
the delay for keystrokes is non-existent.
Now that we mount the react component in the constructor of the wrapper
view, it's never actually visible at the time of mount. By invoking
pollDOM manually after attaching and before emitting the attach event,
the character width is available for the wrap guide to calculate its
initial position.
This prevents a flicker that occurred on theme changes when we just
detected this via polling. I'm going to leave the polling as a catch-all
in case the editor is styled inline in some way.
We sample both the background color of the editor and the gutter. If the
gutter has an actual background color, we use it. Otherwise we fall back
to the same background as the editor.
This ensures lines have an opaque background that matches whatever the
editor is styled as, but avoids the need to apply the .editor-colors
class to the .lines div. That approach fell down when people were
setting the background color via means other than .editor-colors, such
as styling mini editors via the .editor.mini selector in the settings
view.
