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.
In preparation for providing directional pane navigation that goes
beyond the currently-active pane container, this commit:
- Moves the existing directional pane movement specs out of the
PaneContainerElement specs and into the WorkspaceElement specs
- Adjusts the specs to perform all set-up in terms of the workspace, as
opposed to manually constructing a PaneContainer.
Previously the DisplayLayer would have issues when closing tags that had
not been previously opened, requiring us to guard against mismatched
scopes at the frontier of asynchronous tokenization (see 5cfe9716 for
more information).
Now the DisplayLayer gracefully handles closing tags that had not been
opened, meaning we can eliminate this costly logic.
Signed-off-by: Nathan Sobo <nathan@github.com>
This means we may render more tiles than necessary when we have block
decorations, but it prevents changing the number of rendered tiles
during scrolling with certain combinations of line height and editor
height. If it ever becomes a problem we can get smarter about
subtracting the height of the visible block decorations from the editor
height, but for now this gives us more reliable performance for the
common case.
Previously, we were accidentally depending on the state of the display
layer when forcing it to update its index. This caused us to not index
enough content to cover the visibile area, which meant we weren't
querying enough lines to fill the screen in some situations.
This was causing problems in measurements because in that code path we
assume that text nodes are never empty. This commit also adds a test
verifying this invariant when a text decoration ending right after a
text tag is added.
This was leaving a measurement request in the map that was getting
picked up on the next frame. In some cases, the requested measurement
row was not present, causing an exception.
Some packages are interacting with this method assuming this behavior,
so this commit eliminates `screenPositionForPixelPositionSync` and
instead just performs the DOM update in `screenPositionForPixelPosition`
if it is needed.
