What ships
`Client.attached_pane` (and possibly `Client.attached_window`) backed
by the `client_active_pane` format token from `list-clients`,
falling back to the existing `window.active_pane` cascade when the
`CLIENT_ACTIVEPANE` flag is unset on the client.
Problem solved
When a user enables `select-pane -P` (which sets tmux's
`CLIENT_ACTIVEPANE` flag), each attached client tracks an independent
active pane. libtmux today returns the window's active pane regardless,
silently mis-reporting which pane the client is viewing.
The current resolution in `src/libtmux/client.py:Client.attached_pane`
cascades through `session → curw → window.active_pane`. tmux's
`format_defaults` does the same cascade for tokens without `ft->wp`,
but the per-client variant has a different code path:
`server_client_get_pane()` consults `CLIENT_ACTIVEPANE` and returns
the client's own pane when set.
Verified against tmux source:
- `cmd-list-clients.c:90` — calls `format_defaults(ft, l[i], NULL, NULL, NULL)`
- `format.c:5870` — cascade fills `wp = wl->window->active` when `wp == NULL && wl != NULL`
- `server-client.c:2683` — `server_client_get_pane()` honors `CLIENT_ACTIVEPANE`
- `tmux.1:1069` — documents the `active-pane` window option
Why this is its own shipment
Requires:
- Declaring `client_active_pane` as a typed field on `Obj` with the
appropriate `FIELD_VERSION` gate (verify tmux's CHANGES — the
token was introduced before 3.2a, so likely no gating needed).
- A test fixture that enables `select-pane -P` and a second attached
client to exercise the per-client behavior.
- Documentation update for `Client.attached_pane` that distinguishes
the cascade fallback from the per-client resolution.
Material enough to warrant its own review.
Dependency
If #674 ("Type hints for tmux 3.4+ format tokens")
has landed, declaring `client_active_pane` is a lighter touch.
Otherwise this PR will need to declare the field independently.
Acceptance criteria
Refs
What ships
`Client.attached_pane` (and possibly `Client.attached_window`) backed
by the `client_active_pane` format token from `list-clients`,
falling back to the existing `window.active_pane` cascade when the
`CLIENT_ACTIVEPANE` flag is unset on the client.
Problem solved
When a user enables `select-pane -P` (which sets tmux's
`CLIENT_ACTIVEPANE` flag), each attached client tracks an independent
active pane. libtmux today returns the window's active pane regardless,
silently mis-reporting which pane the client is viewing.
The current resolution in `src/libtmux/client.py:Client.attached_pane`
cascades through `session → curw → window.active_pane`. tmux's
`format_defaults` does the same cascade for tokens without `ft->wp`,
but the per-client variant has a different code path:
`server_client_get_pane()` consults `CLIENT_ACTIVEPANE` and returns
the client's own pane when set.
Verified against tmux source:
Why this is its own shipment
Requires:
appropriate `FIELD_VERSION` gate (verify tmux's CHANGES — the
token was introduced before 3.2a, so likely no gating needed).
client to exercise the per-client behavior.
the cascade fallback from the per-client resolution.
Material enough to warrant its own review.
Dependency
If #674 ("Type hints for tmux 3.4+ format tokens")
has landed, declaring `client_active_pane` is a lighter touch.
Otherwise this PR will need to declare the field independently.
Acceptance criteria
falls back to `window.active_pane` when unset
enable `select-pane -P`, focus a different pane in each
client, assert each `client.attached_pane` returns the
correct per-client view
cascade-vs-per-client resolution and references the
`active-pane` window option
Refs
`server-client.c:2683`, `tmux.1:1069`