Sign up
View stargazersSign up

Control-Option-N sends a window to the displays in screen order and reaches every display#333

opened3d agobySSamanyu Das

Note

🤖 Claude Opus 5.5 responding on behalf of Sam

Problem

⌃⌥N sends the focused column to the "next display", but nothing defines which display is next when three or more are connected. In engine 69a2414, to_next_display takes other_displays().next() (src/commands.rs line 1795), the first non-active display in the ECS query. That order comes from the engine's internal storage, not from where the displays are. Reading the code suggests that three displays happen to cycle, that four can skip one display every time, and that a focus change by click can reorder them. This is a code reading, not a live observation, because the test Mac has two displays. Since ⌃⌥⇧←/→ does not cross to a display that touches only at a corner, ⌃⌥N is the default way to reach one.

Proposed behavior

⌃⌥N goes to the next display in screen order: left to right by left edge, then top to bottom, and wraps from the last to the first. With two displays it switches between them, as today. The column still lands after the destination's active column, and focus follows it.

Requested by

Sam, in a design session on 7 November 2026.

Release

v1

Acceptance criteria

  • Engine test with three displays: repeated ⌃⌥N visits each display once in screen order and returns to the first.
  • Engine test with four displays, including one that touches only at a corner: every display is visited once per cycle.
  • Engine test: focusing a display by another command does not change the order.
  • Engine test: with two displays, ⌃⌥N switches between them.
  • With two displays, ⌃⌥N still switches live with verify-miri on a main build. Three or more displays need a hardware check from the v1 acceptance checklist.
  • decisions/keybinding reference.md defines the order.

Alternatives considered

Leave the order undefined. Rejected: a corner display must be reachable.

Dependency and status (coordination, 10 Nov 2026)

  • Builds on another thing? Engine change is paneru#149 (still open draft at 9f7f3441, Sol approved historically). Independent of #332 (already closed via paneru#150 / miri#396). Does not depend on #388/#386/#377/#350/#376.
  • Evidence: paneru#149 engine tests for 2/3/4 displays and focus-order stability pass at 9f7f344. Full engine suite historically green. Two-display live check and Miri pin not yet on main. Three-or-more display hardware check remains blocked.
  • Blocker: 3+ display hardware for the live multi-display criterion. Draft status of paneru#149 until merge authority. Do not waive the 3-display box.
  • Independent work now: ready paneru#149 (undraft when checks still green after rebase onto current miri/v0.5.2 if needed); Miri pin + docs + two-display verify-miri; leave 3+ display criterion unticked.
  • Next step: finish paneru#149 path then Miri pin under GUI lock; hold 3-display hardware.
  • Links: https://github.com/samanyudas/miri/issues/333 · https://github.com/samanyudas/paneru/pull/149
SSamanyu Das4h ago

Note

🤖 Claude Opus 5.5 responding on behalf of Sam

On main at abe13aa1, five of the six criteria hold, and I ticked them. The live criterion stays unticked, because its three-or-more display check still needs hardware, so #333 stays open.

#416 pins engine f1c14be, the merge of paneru#149 into miri/v0.5.2.

CriterionEvidence on main abe13aa1Result
Three displays, each once in screen orderthree_displays_are_visited_once_each_in_screen_orderpass
Four displays with a corner-only onefour_displays_with_a_corner_only_one_are_each_visited_once_per_cyclepass
Focus by another command keeps the orderfocusing_displays_by_other_commands_keeps_the_screen_orderpass
Two displays switchtwo_displays_take_turnspass
Two displays live, and three or more on hardwaretwo displays: verify-miri run 20261110-200936, see below. Three or more: not runheld
decisions/keybinding reference.md defines the orderlines 73-78 and 194, and release-scope.md line 172pass

cargo test next_display on the engine at f1c14be, run from a main checkout: 9 passed, 0 failed. The two extra tests cover displays at the same origin, which follow in display ID order, and displays with different menu bar heights, which do not change the order. Before the fix, at paneru 0029b92, three of the tests failed, including four displays that skipped display 3 on every cycle. CI on main passed in run 42787174479.

Live, with verify-miri under the live-test lock, on a build of main abe13aa1 with the two displays as Sam keeps them: four ⌃⌥N presses moved fixture-1 from display 1 to 3, 1, 3, and 1. Engine focus and macOS focus were on fixture-1 after each press. The display arrangement was unchanged afterwards. No Miri Developer was running before the run, so verify-miri restored the saved window session instead of running its layout check. The engine log shows that the run left a sample window, Helium, at the same frame it had before the run.

Not checked: three or more real displays.