Prior to this change, the following commands successfully move between
panes in the workspace center, but they could not move between the the
panes in the workspace center and panes in the docks:
- window:focus-pane-above
- window:focus-pane-below
- window:focus-pane-on-left
- window:focus-pane-on-right
- window:move-active-item-to-pane-above
- window:move-active-item-to-pane-below
- window:move-active-item-to-pane-on-left
- window:move-active-item-to-pane-on-right
- window:copy-active-item-to-pane-above
- window:copy-active-item-to-pane-below
- window:copy-active-item-to-pane-on-left
- window:copy-active-item-to-pane-on-right
This commit updates these commands to work across all visible panes,
regardless of whether the pane is in the workspace center or a dock.
Summary of approach:
- Add tests for the `nearestVisiblePaneInDirection`, which provides the
core logic for the higher-level methods like `focusPaneViewAbove`,
`moveActiveItemToPaneAbove`, `focusPaneViewOnLeft`, etc.
- Test the generic logic extensively (i.e., the logic that is
independent of whether the given pane resides in the workspace
center or a dock)
- Also test the navigation between docks and the workspace center
- Since the core logic is tested in the new tests above, simplify the
tests for the higher-level methods (e.g., `focusPaneViewAbove`,
`moveActiveItemToPaneAbove`, `focusPaneViewOnLeft`) to avoid
unnecessary duplication.
- Add `nearestVisiblePaneInDirection` to `WorkspaceElement`, implemented
in terms of the existing `nearestPaneInDirection` method on
`PaneContainerElement` for now.
Adding a source map for the entire snapshot was expensive in terms of
memory and seemed to be triggering some sort of bug in Chromium when
reloading with the DevTools open.
The custom row translation relies on a much more compact representation
of the data and avoids the crash.
Signed-off-by: Nathan Sobo <nathan@github.com>
This was removed in #14175 in order to solve #14173 (editors not being
focused when clicking tabs). However, it means that the pane steals
focus from its children. The solution is to add the guard back and to
solve #14173 in another way: by delaying the activation of the item
(see atom/tabs#439).
When calling remote functions or emitting deprecation warnings
respectively Electron and Grim create a fake `Error` object to retrieve
the stack trace of the current call site.
When doing this for the first time, if the call site was located inside
a snapshotted file, previously we would parse the source map for the
snapshot and translate the position of each call in the stack trace.
However, since the snapshot source map is quite big, we were observing
major slowdowns when parsing it for the first time.
With this commit we will parse the snapshot source map while generating
the snapshot, which will allow to not pay for it during runtime.
Signed-off-by: Michelle Tilley <binarymuse@github.com>
