feat: distinguish pinned floats in the minimap (#119)#124
Conversation
|
Warning Review limit reached
Next review available in: 32 minutes Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available. How can I continue?After more reviews become available, a review can be triggered using the To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews. How do review limits work?CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability. For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window. Please refer docs for additional details. Review details⚙️ Run configurationConfiguration used: defaults Review profile: CHILL Plan: Pro Run ID: 📒 Files selected for processing (23)
✨ Finishing Touches🧪 Generate unit tests (beta)
Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
Codecov Report❌ Patch coverage is
📢 Thoughts on this report? Let us know! |
There was a problem hiding this comment.
Pull request overview
This PR adds pinned-floating-pane awareness to the zellij-tabmap minimap so pinned floats are visually distinguishable and hidden floating layers are depicted accurately (pinned floats remain as overlays; only unpinned floats chip).
Changes:
- Add dump-driven pinned-float detection (
dump_session_layout_for_tabKDL scan + geometry correlation) and thread pinned ids through the render pipeline. - Introduce
FloatSpec/FloatLayer::Mixedto represent hidden layers with pinned overlays + unpinned chips. - Render a
⌖corner marker on pinned float overlays and update wheel/focus traversal semantics to treat hidden pinned floats as visible.
Reviewed changes
Copilot reviewed 22 out of 22 changed files in this pull request and generated 1 comment.
Show a summary per file
| File | Description |
|---|---|
| src/lib.rs | Maintains pinned_by_tab, partitions hidden float layers into Mixed, and updates wheel/focus traversal to include hidden pinned floats. |
| src/pinned.rs | New pure KDL scanner + geometry correlator to resolve pinned float ids from per-tab layout dumps. |
| src/floating.rs | Adds Mixed { chips, overlay } variants to carry hidden-layer pin partitions. |
| src/minimap.rs | Threads pinned_floats into render, supports Mixed, and stamps the ⌖ pin marker on pinned overlays. |
| src/paint.rs | Threads per-tab pinned-float ids into tab_block::assemble. |
| src/tab_block.rs | Threads pinned_floats through assembly into minimap::render. |
| README.md | Documents the pinned-float marker and mixed hidden-layer behavior. |
| .claude/rules/zellij-plugin-development.md | Adds a rule documenting the dump/KDL route and related constraints for pinned state. |
| docs/superpowers/specs/2026-07-17-pinned-floats-design.md | Adds the pinned-floats design spec. |
| docs/superpowers/specs/2026-07-16-float-labels-design.md | Updates deferred scope notes to reflect #119 shipping separately. |
| docs/superpowers/specs/2026-07-12-floating-panes-in-minimap-design.md | Reconciles prior “blocked” pinned-float note with the dump-based approach. |
| docs/superpowers/plans/2026-07-17-pinned-floats.md | Adds the implementation plan document for #119. |
| examples/render_pinned.rs | New example to visually demonstrate pinned floats + mixed hidden-layer behavior. |
| examples/render_top_label.rs | Updates paint::bar call to pass pinned-float ids map. |
| examples/render_perspective.rs | Updates paint::bar call to pass pinned-float ids map. |
| examples/render_palette.rs | Updates paint::bar call to pass pinned-float ids map. |
| examples/render_new_tab_button.rs | Updates paint::bar call to pass pinned-float ids map. |
| examples/render_gradient.rs | Updates minimap::render call to pass pinned-float ids slice. |
| examples/render_floating.rs | Updates paint::bar call to pass pinned-float ids map. |
| examples/render_demo.rs | Updates paint::bar call to pass pinned-float ids map. |
| examples/render_close_button.rs | Updates paint::bar call to pass pinned-float ids map. |
| examples/render_active_cue.rs | Updates paint::bar call to pass pinned-float ids map. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: a28683a041
ℹ️ About Codex in GitHub
Your team has set up Codex to review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
Codex can also answer questions or update the PR. Try commenting "@codex address that feedback".
| // the click routes to a chip or the tiled pane instead. | ||
| visible_floats: match floats_by_position.get(&hit.position) { | ||
| Some(floating::FloatSpec::Visible(rects)) => rects.clone(), | ||
| Some(floating::FloatSpec::Mixed { overlay, .. }) => overlay.clone(), |
There was a problem hiding this comment.
Prioritize overflow chips over mixed overlays
When a hidden layer is Mixed and enough unpinned floats overflow, this records the pinned overlay for hit-testing; route_click checks float_overlay_at before chip_marker_target_at, while render paints the ⋯ overflow chip above the overlay. If that bottom-right marker lies over the pinned overlay, clicking the visible ⋯ focuses the pinned pane instead of revealing the first folded float, making the overflow marker unreachable in that common mixed-layer layout.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Confirmed — the marker paints above a Mixed layer's pinned overlay (the chip run owns its row) but resolved after it, so draw and hit-test disagreed on that cell. Fixed in a5a180c: the chip run (float_chip_at → chip_marker_target_at) now resolves before float_overlay_at, with a regression test (route_click_lets_the_marker_beat_a_pinned_overlay_beneath_it).
| // the click routes to a chip or the tiled pane instead. | ||
| visible_floats: match floats_by_position.get(&hit.position) { | ||
| Some(floating::FloatSpec::Visible(rects)) => rects.clone(), | ||
| Some(floating::FloatSpec::Mixed { overlay, .. }) => overlay.clone(), |
There was a problem hiding this comment.
Avoid revealing hidden floats from pinned overlays
For a hidden Mixed layer, these pinned panes are recorded as visible_floats, so clicking the pinned overlay follows the existing FocusFloatingPane path and dispatches focus_terminal_pane(id, true, false). That true flag is correct for hidden chips because it reveals the floating layer, but for a pinned pane that is already on screen it also unhides the unpinned floats in the tab; clicking the pinned overlay should focus it without popping the rest of the hidden layer open.
Useful? React with 👍 / 👎.
There was a problem hiding this comment.
Checked against zellij 0.44.3: Tab::focus_pane_with_id calls show_floating_panes() unconditionally whenever the focused pane is floating (zellij-server/src/tab/mod.rs:5254-5261); the should_float_if_hidden flag is only consulted for suppressed panes. So passing false here would change nothing — focusing any floating pane through the host API always reveals the layer, and "focus without unhiding the rest" is not expressible with the current zellij surface. The reveal also matches what zellij itself does when a pinned pane gets focused while the layer is hidden, so the bar stays consistent with native behavior. Happy to revisit if a future zellij exposes a non-revealing focus.
Co-authored-by: Copilot Autofix powered by AI <175728472+Copilot@users.noreply.github.com>
Closes #119.
On the active tab (⌘2) the float layer is visible: the pinned
htopfloat carries a⌖pin marker in its top-right corner while the unpinnedlogsfloat stays unmarked. On ⌘3 the floating layer is hidden — yet its pinnednotefloat keeps its overlay box (marker dimmed with the inactive tab), and only the two unpinned floats fold into◲chips.What & why
zellij's
toggle-pane-pinnedkeeps a float on the real screen even while the floating layer is hidden. The bar previously (a) could not tell pinned floats apart at all, and (b) mis-depicted a hidden layer by folding every float into a chip — a pinned float is actually still on screen. This PR adds the visual cue and makes the hidden-layer depiction honest.Design decisions (per spec)
⌖corner marker, plain Unicode — joins the existing◲ ◳ ⋯vocabulary; deliberately no Nerd Font dependency.◳), bg the float's fill; inactive tabs blend the fg byINACTIVE_LABEL_BLEND. Labels stop one cell short of the corner, so marker and title never collide.FloatSpec::Mixed), only unpinned floats chip; a layer with no pins renders byte-identically to before.panescrolling and anchoring treat them as visible; hidden unpinned floats stay chip-only (feat: show floating panes in the minimap, selectable when hidden #110 semantics preserved).dump_session_layout_for_tab, which needs only the existingReadApplicationStategrant, so the #15 bar-freeze trap can't trigger for existing users.How it works
PaneInfonever exposes a pinned flag, and a pin toggle arrives as aPaneUpdatewith no field changed — the one read path is the session-layout dump (spike + zellij 0.44.3 source verified; now rule #20):pinned.rs(new) — dependency-free line scan of the dump KDL: collectsx/y/width/height+pinned trueundertab > floating_panes > pane(template blocks likeswap_floating_layoutare scoped out), then correlates the pinned rects back to manifest float ids by exact cell-geometry equality (the KDL carries no pane ids). Percent coords, malformed input, and geometry twins all degrade gracefully — the cue is additive, the bar never stalls.lib.rs—refresh_pinned()re-dumps float-bearing tabs on everyPaneUpdate(manifest-keyed caching would miss pin toggles) intopinned_by_tab; the host call sits behind a#[cfg(test)]-stubbed seam (rule #17 — the shim reads stdin and panics off-wasm), with the whole decision path (pinned_ids_for_tab) pure and natively tested.floating.rs— newFloatSpec::Mixed { chips, overlay }for the partitioned hidden layer; the router needed no change (chips and overlays already coexist inTabPaneGeom).minimap.rs— stamps⌖in a pinned overlay's top-right corner cell, gated to boxes ≥ 2 cells wide whose corner pixels the float actually owns; chips keep corner precedence.is_pinnedpredicate letsfocused_pane_idandpane_focus_orderinclude hidden-layer pinned floats.Testing
CARGO_BUILD_TARGET=aarch64-apple-darwin cargo test --lib→ 354 passing (new: KDL parser fixtures incl. template-block exclusion and percent skip, geometry correlation & twins, Mixed rendering + marker size/occlusion gates, hidden-layer partition paths, per-tab pin scoping, wheel/anchor inclusion + unpinned-beside-pinned boundary).cargo clippy --target wasm32-wasip1 --all-features --lib→ clean.cargo build --target wasm32-wasip1andcargo build --examples --target aarch64-apple-darwin→ build.cargo run --example render_pinned --target aarch64-apple-darwin→ the visual above.Deferred (out of scope, per spec §5)
Pin/unpin actions from the bar, chip-level pin distinction (a pinned float never chips), and dump-call throttling.