This makes observeActiveTextEditor consistent with observers like
observeActivePaneItem, which always invoke the callback with the current
value, regardless of whether that value is undefined or not.
Fixes the following bug:
1. Open Atom
2. Open a file
3. Observe the file's encoding in the status bar
4. Reload Atom
5. Close the file
6. Observe that the closed file's encoding is still present in the
status bar
This bug occured because the reload did not deserialize/serialze the
workspace's active text editor state. As a result, when closing the
text editor in step 5, we failed to notify observers that there is no
longer an active text editor.
WorkspaceCenter's observeTextEditors method calls
this.onDidAddTextEditor, but WorkspaceCenter didn't have an
onDidAddTextEditor method. This commit adds a test for
observeTextEditors and it adds the missing onDidAddTextEditor method to
make the test pass.
Dock's observeTextEditors() method calls this.onDidAddTextEditor(), but
Dock didn't have an onDidAddTextEditor method. 🙀
Dock's observeTextEditors() method also calls this.getTextEditors(), and
Dock's getTextEditors() method calls
this.paneContainer.getTextEditors(), but there is no getTextEditors()
method on this.paneContainer. 🙈
This commit adds a test for observeTextEditors, and it adds the missing
onDidAddTextEditor method, and it fixes the getTextEditors method to
make the new test pass.
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.
