step between open windows - #591
Merged
Merged
Conversation
`hostPID()` read `session-host.pid` on the first try, but the host writes it from its own process after the client that started it returns. `waitForLeaders` proves the zmx daemons are up, which is a different event. Unloaded the file was already there, so the race only showed in a full-suite run, where `ControlServerZmxTests.testRealClientPaneChangesFromSupervisorToOrphanedWhileBarePaneReadsApp` failed with ENOENT while passing on its own.
new `previous_window`/`next_window` builtins, Navigate ▸ Previous/Next Window, two palette rows, and `window.go --to next|prev`. Window was the only level of the hierarchy with no prev/next: sessions, attention sessions, workspaces and panes all had one. Both builtins ship keyless, like the workspace pair, so nothing takes a chord from anyone. host-free `WindowLibrary.navigateWindow` is the one step every surface calls. It walks the OPEN windows in library order, wrapping. A closed bundle is not a stop on the way round, so the cycle length matches what is on screen rather than what the library holds, and `window select` stays the verb that opens one. both surfaces raise through `WindowRegistry.raise` and publish frontmost themselves. Going through `AppActions.openWindow` instead would be wrong twice over: on a failed raise that hub enqueues a claim and opens a fresh scene, and the failure case for a step is an open window still attaching, so one store would get two scenes. `enqueueClaim` dedups pending claims only, so a popped claim does not protect it. And `WindowAccessor.reportFrontmost` rides `didBecomeKey`, which never arrives while agterm is inactive, the state a step from the quick terminal raises in, leaving the id stale so every later step recomputes from the same origin. `AppActions.swift` and two test files were at the swiftlint limit, so the navigation block moved to `AppActions+Navigation.swift` and the window cases to `WindowCommandsTests.swift` and `ControlWindowProtocolTests.swift`.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
a user asked whether the missing cycle-between-windows action was deliberate. It was not, so here it is.
agterm had prev/next for sessions, attention sessions, workspaces and split panes. Window was the one level of the hierarchy with nothing, which left ⌘
(a macOS shortcut you can turn off and cannot rebind per app) or a script overagtermctl window list`.What is new
previous_window/next_windowkeymap builtins, both keyless, somap cmd+opt+[ previous_windowis yours to writeagtermctl window go --to next|prevHow the step works
One host-free
WindowLibrary.navigateWindowbacks all three, so menu, palette and CLI cannot drift. It walks the OPEN windows in library order and wraps. A closed bundle is not a stop on the way round: the cycle is as long as what is on screen, andwindow selectstays the verb that opens a closed one. Below two open windows the GUI items disable throughPaletteContext.canStepWindowsandwindow.goanswersno other open window to navigate to.Two things worth a second look
Both surfaces raise through
WindowRegistry.raiserather than theAppActions.openWindowhub. On a failed raise that hub enqueues a claim and opens a fresh scene, and the failure case for a step is an OPEN window whose NSWindow has not attached yet, so one store would end up with two scenes and closing either would tear down surfaces the other is showing.enqueueClaimdedups pending claims only, so a claim already popped does not protect it.AppActionsTests.testWindowStepNeverOpensASceneForAnUnattachedTargetpins it.Both also publish frontmost themselves.
WindowAccessor.reportFrontmostridesdidBecomeKey, which AppKit does not deliver while the app is inactive, and the key monitor fires a bound step from the quick terminal with agterm in the background. Without the explicit publish the id stays stale, every later step recomputes from the same origin and picks the same window, and an auto-hidden sidebar stays collapsed on the window just raised.Also in here
AppActions.swift,CommandsTests.swiftandControlProtocolTests.swiftwere all sitting exactly at the swiftlint file limit, so they are split at existing seams:AppActions+Navigation.swift,WindowCommandsTests.swift,ControlWindowProtocolTests.swift. The moved code is verbatim.One unrelated fix rides along, in its own commit.
SessionHostClientTests.Fixture.hostPID()read the session-host pidfile once, while the host writes it asynchronously, soControlServerZmxTests.testRealClientPaneChangesFromSupervisorToOrphanedWhileBarePaneReadsAppfailed with ENOENT under full-suite load and passed on its own. It polls now.Docs updated:
site/docs.html,site/commands.html, the bundled skill, and the windows/control-api/menu-actions/keymap rules.