This ensures the drive letter is consistent on Windows for when
package paths are compared to the resources path to determine
whether to use the metadata cache for a bundled package.
Closes#3932
Do it previously in window-bootstrap caused several things to not be
included such as requiring coffee script and atom shell modules.
Now it is a much more accurate representation of on load time.
These were currently undocumented in the styleguide, had hard-coded colors,
weren't being styled by the default light/dark UI themes, and were unused.
They were also causing conflicts with the notification token scope that
the Objective-C grammar uses.
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.
Trying to make the .highlights layer double as the .underlayer was
causing GPU artifacts on the wrap guide when the last highlight was
removed. This puts it in its own layer to avoid that.
Previously, when the last highlight div was removed from the lines
layer, chunks of the lines would sometimes disappear. Since we've
discovered that giving the lines an opaque background doesn't help with
subpixel anti-aliasing anyway, I've found that rendering highlights on
their own layer behind the lines and making the lines layer transparent
avoids the arficacts.
Previously, we stopped propagation on mousedown events to prevent
certain cases where focus was being lost after double clicking to select
a word.
Unfortunately, this also broke the ability to focus the editor by
clicking it. When investigating this, I noticed that whenever we lost
focus, the target of the mousedown event was always the cursor. So I
tried setting `pointer-events: none` on cursors and can no longer
reproduce the double-click issue.
/cc @probablycorey
Things depend on the react editor wrapper having the .editor class,
but inside the editor, we can control the style. I changed the
component's div to be .editor-contents for now. We can eliminate this
extra style when we eliminate the wrapper.
It is difficult to scroll through stack traces when there are huge
failure messages. This limits the length to 10 lines, if you hover
over the message it will expand.
Somewhat related to #1173
Horizontal / vertical scrollbars render a 'corner' on the lower right
when they would otherwise overlap. I previously relied on drawing both
dummy scrollbars at their full width/height so the corner got rendered,
but that interfered with the display of the horizontal scrollbar in
certain circumstances because it was too wide to scroll. This commit
provides that behavior with an absolutely positioned div with the same
dimensions as the intersection of scrollbars when both are visible.
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.
The space-pen view is now a simple wrapper around the entire React
component to integrate it cleanly into our existing system. React
components can't adopt existing DOM nodes, otherwise I would just have
the react component take over the entire view instead of wrapping.
With Node.js baked in, there's no water-tight way to prevent users from
evaluating code at runtime, at least with CSP alone. This is because
node exposes a 'vm' module that allows scripts to be compiled. There's
also `module._compile`, etc.
I think a reasonable compromise is to protect users from eval'ing code
by accident. This commit adds an atom.allowUnsafeEval method which
re-enables eval in the dynamic scope of the given function.
I then use this to compile the keystroke grammar which saves us the
complexity of pre-compiling it during specs.
What do people think?
