`onDidChangeActivePaneItem` is called synchronously when the active pane
item changes, and several non-critical actions preform work on that
event. Critical UI feedback, like changing the active tab, needs to
happen synchronously, but most other functionality should be run
asynchronously.
This prevents a bug where calling `::getView` returns two different instances if
such method is invoked after views are cleared out (e.g. packages deactivation
in `packageManager.reset()`).
Now that we have deleted `Project::open(...)`, all the methods that previously
used it need to switch to `Workspace::open(...)` instead. These two methods,
however, are not idempotent because the latter performs additional operations.
Since some specs relied on not activating an item after opening it, this commit
adds a parameter to prevent such activation.
Refs: 1ebcf166c7
This prevents a 🐛 where the `onDidLoadBundledKeymaps` was fired before
`MenuManager` had the chance to listen to it thereby not showing the appropriate
menu entries.
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.
