This was previously needed when we applied 'editor-colors' to the
line numbers to give them an opaque background in hopes of supporting
sub pixel AA, but that dream is dead for now anyway. This makes the
gutter harder to style, so I'm nixing it.
I'm not adding a default for this one so it won't show up in the
settings view unless the user sets it in their config explicitly. I'm
hoping it won't need to be flagged for very long.
Enable sync updates and manually invoke the pollDOM function on the
component when we call hide/show on the wrapper view. This ensures that
we perform initial measurements when showing the editor for the first
time.
Having the editor-colors class on these elements was causing the theme
to be applied to lines in mini editors in the settings view, which
caused a black inset box to appear with dark syntax themes.
This was added to give the lines an opaque background which was supposed
to enable sub pixel anti-aliasing despite being on the GPU, but it
didn't seem to be working. Perhaps we can revisit this issue after the
Chrome 35 upgrade to see if sub pixel antialiasing works with opaque
backgrounds afterward.
Previously, these measurements were always performed when the editor
component was mounted. This didn't work in situations where the
component was mounted in a non-visible state. This commit includes a
visibility check in the resize polling we were already doing, kicking
off the measurement process as soon as the editor is visible.
This doesn't seem to adversely affect the scroll experience, and it's
much simpler. I want to avoid preventing the default action of
mousewheel events if they don't actually lead to scrolling, and making
the behavior synchronous will make that a lot easier.
This makes the actions that we perform in the poll loop explicit, and
will prevent the accumulation of polling-related behavior in the
::measureScrollView method.
This allows the line height to be styled via CSS. I would actually
like to allow all these properties to be assigned via CSS rather than
explicitly via the settings view, but that can be deferred until the
old editor is removed.
The goal is to make the editor behave like a standard block-level
element.
The horizontal behavior is simple: we stretch horizontally to fill our
container.
The vertical behavior is more nuanced. If an explicit height is assigned
on the wrapper view, we honor that height. But if no explicit height is
assigned, the editor stretches vertically so that its contents are
visible.
This prepares us to support mini editors, which need to be 1-line tall
without an explicit height assignment.
Just a few suggested changes to reflect experiences over a few months of building on several Windows machines.
- The Posix tools comment doesn't seem to be applicable (anymore)?
- Added further instructions when using pre-installed Git.
- Added the frequent issue of first-time build failures (random `node-gyp` errors), which don't reoccur on second try.
- Added a few extra words on opening a new issue, to clarify that appropriate details should be provided, if the issue hasn't been reported before.
Feel free to amend or suggest further changes.
