Log output to stderr as we did before, so that grunt can, in turn, output it to
console when specs fail.
Welcome back build failures! 🎉
/cc: @nathansobo @maxbrunsfeld
According to these specifications:
Portable mode only applies to Windows (for now)
Portable mode only applies if ATOM_HOME is not set
If there is a .atom directory as sibling to directory with running process
use that as ATOM_HOME
The idea with this commit is to implement a timeout functionality that does not
rely on a system utility (such as unix `timeout`). Tests could hang because of a
CPU-bound task and, as a result, we need to handle timeouts in a separate
process.
An ideal implementation would first spawn the timeout, which in turn would spawn
the tests, acting as a supervisor and making sure they do not exceed the
supplied time. However, setting up such an environment would have been trickier,
thus the test process spawns the timeout cop before running any test. This, in
turn, invokes a `setTimeout` function and kills the parent process as soon as
the timeout gets triggered, logging to console the reason why the parent process
was killed (and exiting the parent process with code 130).
I haven't used `Task` because, in order to log stuff to the console, we need to
fork the ChildProcess from `remote`, as otherwise nothing gets written out.
If the nearest containing package.json of a test path has an
atomTestRunner field, we’ll require the specified file as a test runner
rather than the default jasmine runner.
For some reason, logging to stderr/stdout from the render process only
works when Atom is run via child_process.spawn, which is how `apm test`
invokes it.
I’m trying to make a convenient interface for running tests directly via
the `atom` command, and this is the only way I could find to long to
stdout from the render process.
I’m also choosing stdout rather than stderr because in this case, you’re
intentionally running the tests and want to see feedback.
For certain font sizes, enabling `textRendering: optimizeLegibility` caused a
bunch of measurement-related issues. You can reproduce it by setting the following in your stylesheet:
```
atom-text-editor {
font-size: 14px;
text-rendering: optimizeLegibility;
}
```
Although I wanted to defer subpixel font scaling to a later moment, it seems
like Chrome needs to have it enabled in order to properly support the
"legibility" path for text rendering. (I guess this is part of the reason why
the Chromium team enabled it by default at some point in the past.)
Fix the bug where Open With Atom on Windows machines will fail for paths
containing spaces. Wraps quotes around the path to the Atom executable
in the reg key string.
