sl0ppi.git/sl0ppij/zellij-server/src, branch main

sl0p: the plugins we ship do not ask for permission

2026-08-13T18:08:50Z

pane-finder requests three permissions as it loads, so the first press of a keybinding we ship opened a consent screen instead of a fuzzy finder. Prompting is right for a wasm you found on the internet and wrong for the ones that come in our own tarball. plugin_is_shipped_with_sl0ppi (zellij-utils/src/input/permission.rs) grants those implicitly, through the same instruction a human "y" produces, so the plugin's permissions are set and recorded exactly as before. "Ours" is narrow on purpose: - builtins, asked via the existing PluginConfig::is_builtin -- the same predicate check_command_permission already uses to exempt them, so the two cannot drift; - files inside a plugin directory we install into: the config dir's plugins/ and the data dir's plugins/; - nothing else. Remote plugins are never trusted, paths are normalised lexically first so plugins/../../evil.wasm is not "inside" the dir, and the directories are derived from the environment and default locations -- so getting them wrong costs a prompt and can never grant one elsewhere. The trade, documented in config/README.md: /plugins/ is now a trusted directory. Anything able to write there can already bind arbitrary commands to a key in config.kdl, so a consent screen for the wasm beside it was not buying anything -- but it does mean plugins/ is not a download folder. packaging/checks/plugin-permissions-live.py drives both halves on a real session: the shipped plugin must run without the prompt, and the SAME wasm loaded from outside the plugin dir must still ask. Confirmed by disabling the rule and watching the first half fail with the exact "asks permission to ... Allow? (y/n)" screen it was written against.

sl0p: make the split button work on stacked panes too

2026-08-13T17:39:18Z

Reported still dead on a live session after the previous fix. Stacks move the frame twice more, and neither move was in the hit-test: - a stack list is drawn over the top rows of its visible member, pushing that pane's frame down. The renderer applies this as a frame geom override (reserved_top_rows); the click side did not, so every pane in a stack was clickable one row above its own title. frame_rect_with_top_reserved() now applies the same shift, before the gap inset, in the same order as render; - a stack's collapsed members drew a button on their one-row title. Nothing could honour it -- that row is the stack's picker, and "split the pane that is not on screen" is not a thing to ask anyway. They no longer draw one, and the click side mirrors the condition. 120 snapshot lines change, every one of them a one-liner losing its button and nothing else (same width, same content otherwise; audited mechanically). Both confirmed by reintroducing each bug and watching the check fail. A third candidate fix -- resolving a click to the stack's visible member, on the theory that get_pane_at could return a collapsed sibling -- turned out to be unnecessary: collapsed members have one-row geoms, so position lookup already lands on the right pane. Removed rather than kept "just in case". The check itself was wrong twice before it was right, in the direction that matters most (reporting failures that were its own): it now reads until the pty goes quiet instead of for a fixed time, and parses only a freshly forced repaint, so a half-arrived screen cannot look like a button drawn where it is not. It clicks every button it can see, and runs against config/config.kdl as well, whose stacks the minimal config never had. When the two disagree, the server's own log settles it: log::info! in intercept_split_button_click, read /tmp/sl0ppij-$UID/sl0ppij-log/.

sl0p: make the split button visible, and clickable where it is drawn

2026-08-13T16:46:58Z

The `+` shipped in 0.1.7 and 0.1.8 without ever appearing on a live session, while rendering in 265 snapshots. Four faults, each enough on its own: - title_line_without_middle computed the right side only inside the left side's and_then, so a pane with no title (hide_default_pane_names, the live default) got none at all; - title_line_with_middle discarded the right side whenever the left was absent -- that is every frame in a session with a second client, which the live box always had, and "MY FOCUS AND:" on every frame was saying so; - the title was budgeted before the button, so a title longer than the frame (any shell showing a path) consumed its columns. The button is anchored and hit-tested by pure geometry, so it cannot be the part that loses; - the click hit-tested position_and_size() while the frame is drawn inset by the pane gap, putting the clickable columns two right of the glyph and a row above it at the top of the screen. Hence "the click works" and "nothing is drawn" both being true, and that click test proving nothing. Adds Pane::frame_rect(), the rect the frame is really drawn in, which the status bar buttons had already had to work around by hand. Also fixes render_my_focus building its short form from separators that Vec::append had already drained: 4 cells wide while reporting 6, a title line two cells short of its pane. Found by asserting the width in the new test. Verification, since unit tests have now been insufficient here four times: split_button_is_drawn_where_it_is_hit_tested covers the combinations the live config produces, and packaging/checks/split-button-live.py (make check-live) reads the glyph off a real session, attaches a second client to force the middle builder, and clicks the columns it found the glyph in. Both confirmed to fail on the parent commit.

sl0p: account for the split button in the title-alignment test

2026-08-13T12:47:20Z

A right-aligned title no longer runs flush to the corner: the split button now occupies SPLIT_BUTTON_WIDTH columns between them. Adjusts the expectation rather than the layout, since that gap is the intended design.

sl0p: draw the split button always, not only on hover

2026-08-13T12:46:03Z

The hover-gated version did not work. `mouse_is_hovering_over_pane` never became true in a live session, so the `+` was invisible while its hit-test -- which is geometric and never consulted hover -- kept working. Clickable but invisible is the worst of both, and it is exactly the failure the shared `split_button_columns()` was supposed to prevent: that guarantees render and hit-test agree on WHERE, not on WHETHER. Reported as "I hover over panes but don't see a +". My end-to-end test had proved the click, not the button, and the passing snapshots only proved the renderer works when the flag is set. Why the flag is false live is still open and is written into the code comment: the plumbing from `mouse_hover_pane_id` through `FrameParams` reads correctly, and the config that reproduces it sets both `advanced_mouse_actions` and `mouse_hover_effects`. Re-gate on hover only once that is understood AND shown on a real session rather than in a snapshot. 265 snapshots updated: every pane frame now carries the button. 233 are mechanically provable as button-only (the ` + ` replaces three horizontal glyphs before a corner); the remaining 32 differ only by a header line offset in the comparison, with the same substitution underneath.

sl0p: a mouse affordance for splitting a pane

2026-08-13T12:04:23Z

Switching panes, switching tabs, renaming, reordering and resizing all have a mouse path in this fork. Spawning a pane did not: it was keyboard-only. A `+` now appears at the right end of a pane's title line while the pointer is over that pane, and clicking it splits the pane. Hover-driven rather than always drawn, for the same reason the resize hint and the status bar button highlight are: a permanent `+` on every frame is noise, and the pointer being there is exactly when the button is useful. render ui/pane_boundaries_frame.rs::render_split_button hit tab/mouse_handler.rs::intercept_split_button_click shared split_button_columns(), so what is clickable is what is visible The button sits immediately left of the top-right corner and the existing scroll and pin indications get the room that is left. That ordering is deliberate: a fixed position relative to the pane's right edge is one the mouse handler can hit-test directly, instead of re-deriving the whole title layout the way `status_bar_button_at` has to. The clicked pane is focused first, then the split is requested exactly as a keybinding would (`PtyInstruction::SpawnTerminal` with `NoPreference`), so mouse and keyboard produce the same arrangement and the split lands on the pane whose button was clicked rather than whichever pane happened to be focused. Not drawn on floating panes: their PIN control owns that corner and is hit-tested by its drawn position, so anything to its right silently moves it out from under the pointer. Caught by test_ctrl_click_on_floating_pin_button_toggles_pin, which stopped pinning. Verified on the test box by injecting real SGR mouse events into an attached client's pty at 160x45: click on the button 1 -> 2 panes click on the title 1 -> 1 click mid-frame 1 -> 1 Two hover snapshots updated, and only those two: the `+` on the hovered pane (including an unfocused one -- splitting a pane you are not in is useful). zellij-server 1502 pass, zellij-utils 473 pass.

sl0p: resolve responsive layouts against hidden panes too

2026-08-13T11:35:38Z

A pane created after a responsive collapse/expand cycle was absorbed into a stack, even at full width. Reported as "a new pane starts collapsed even though the terminal is big enough", and it appeared to fix itself on resize. The expand was never really happening. `SwapLayouts::tiled_layout_at` checked whether a candidate layout fits by positioning it against `tiled_panes.visible_panes_count()` -- and a stack hides every member but one. So while collapsed, the check ran with a pane count of 1, and a layout with no room for the hidden panes passed as feasible. The tab reported `sl0p:responsive-expand` while every pane stayed in the single rect it had while collapsed; the next pane added simply joined that stack. Feasibility is now checked against every tiled pane, hidden or not, which is the count the layout actually has to accommodate. Only the responsive collapse/expand resolves layouts through this function -- ordinary swap-layout cycling has its own body in `swap_tiled_panes` -- so the change is contained to the path that was wrong. Verified on the test box (responsive_min_cols 90) with a scripted pty that resizes mid-session, geometry read back from `list-panes --json`: before narrow(80) 2 panes -> one rect, both 80x23 (correct collapse) widen to 160 -> STILL one rect, 160x44 (expand did nothing) add a pane -> new pane joins the stack after narrow(80) 2 panes -> one rect (collapse unchanged) widen to 160 -> x=0 and x=80, side by side (really expanded) add three panes -> 2+1, then 2x2, then 3+2 grids, no shared rects wide from the start -> unaffected narrow again (70) -> collapses, as before No unit test ships with this, deliberately. Three attempts could not make one discriminate: the tab harness does no rendering, so nothing populates `panes_to_hide` and both counts are equal; hiding panes by hand does not help because the harness's expand takes the BASE path; and asserting on the resolver directly bypasses the count, since `tiled_layout_at` uses it only for the feasibility check and returns the raw layout. A test that passes with the fix reverted is worse than none, so the scripted live reproduction above is the verification, and it is written down in docs/roadmap.md to be re-run. zellij-server 1502 pass, zellij-utils 473 pass.

sl0p: stop recycling client ids, which silently ate CLI output

2026-08-12T22:33:31Z

`zellij action` failed ~20% of the time against a live session: exit 0, empty stdout, empty stderr, and nothing in the server log. `sl0ppi ls` inherited it, and attached clients were dropped with "lost connection to the zellij server". The chain, which took measuring rather than reading to find: 1. every action first probes liveness (sessions::assert_socket): connect, send ConnStatus, disconnect. The probe is a full client and takes an id. 2. new_client() handed out the LOWEST FREE id, so the action connection that follows microseconds later gets the id the probe just released. 3. the main server thread then processes the queued ConnStatus(id), whose handler replies and calls remove_client!(id) -- removing the *action* client, which now owns that id. 4. the action's reply goes through send_to_client, which returns Ok(()) for an unknown client. The payload is dropped in silence; the client sees only the disconnect and exits 0 with nothing to print. Fix: hand out ids from an advancing cursor instead of reusing the lowest free one, so a stale removal cannot land on a fresh connection. ClientId is a u16 and every CLI invocation burns two, so the cursor wraps and skips ids that are still in use rather than assuming they are free. Measured on the 2-vCPU Debian box that surfaced this: before after list-tabs ~20-25% 0/50 failed list-panes ~20-25% 0/50 failed list-tabs (attached) ~25% 0/30 failed sl0ppi ls most runs 0/15 failed 5 attach cycles dropped 5/5 stable Three regression tests: ids are not reused immediately, they advance and skip live ones, and they wrap without colliding or hanging. zellij-server: 1502 pass. The silent-drop in send_to_client is left as-is but is worth revisiting: an unknown client id is a bug in the caller, and swallowing it is what made this cost a day instead of a minute.

sl0p: stop suspended panes spamming resize errors

2026-08-12T22:04:44Z

Attaching to a session of `start_suspended` panes could drop the client with "your zellij client lost connection to the zellij server", and `zellij action` against that live session failed most of the time. Cause: `set_terminal_size` treats "no fd for this terminal id" as an error, but a reserved-and-not-yet-started terminal is exactly what `start_suspended` (and any held pane) is. Resizes arrive in cached bursts (ResizeCache), so every attach and every layout change logged one formatted, contexted, file-written error PER suspended pane, on the server's hot path. The map distinguishes the two cases already -- `Some(None)` is reserved-without-fd (reserve_terminal_id), `None` is genuinely unknown -- so the fix is to match them separately and stay quiet about the former. Measured on a 2-vCPU Debian box, `action list-tabs` against a live session: before 2 suspended panes 5/12 failed 2 plain panes 1/12 failed after 2 suspended panes 6/30 failed 2 plain panes 9/30 failed resize errors logged: 126+ -> 0 ie. the suspended-pane penalty is gone; what remains is a separate baseline failure rate that affects plain sessions equally (see the known issue in docs/roadmap.md). zellij-server: 1499 tests still pass.

sl0p: rename to sl0ppij behind a branding seam

2026-08-12T18:02:26Z

Makes the fork installable and runnable beside a stock zellij: separate binary name, config dir, cache dir, socket dir, log file and plugin URL scheme. Everything user-visible is defined once in zellij-utils/src/branding.rs and referenced from the ~15 places that used to hold a literal, rather than sed-ing the tree -- upstream has 3300 commits of future rebases, and each touched upstream line is a conflict forever. A conflict in branding.rs itself always resolves the same way: keep our constant, take their code. binary zellij -> sl0ppij config dir ~/.config/zellij -> ~/.config/sl0ppij system cfg /etc/zellij -> /etc/sl0ppij cache/data ProjectDirs(Zellij) -> ProjectDirs(foo.sl0p.sl0ppij) socket/tmp /tmp/zellij-$UID -> /tmp/sl0ppij-$UID log zellij-log/zellij.log -> sl0ppij-log/sl0ppij.log plugin urls zellij:tab-bar -> sl0ppij:tab-bar (zellij: still parses) Two things deliberately NOT renamed: - The cargo package stays `zellij`; only [[bin]] is renamed. Renaming the package would ripple through every intra-workspace dep, the plugin API and the 0.45.0+sl0p1 version trick for a name nobody sees. - The $ZELLIJ* environment variables stay, because the ecosystem (shell prompts, "am I in a multiplexer" checks, our own pi-ext) looks for them. We now export $SL0PPIJ* alongside them, and those take precedence on read. branding::import_compat_env() folds an inherited ZELLIJ_CONFIG_DIR into its SL0PPIJ_ spelling at startup, before clap reads the environment -- clap can only be told one variable name per argument. Snapshots: 14 updated, all of them the plugin URL scheme or a session message. The insta churn (assertion_line metadata, trailing newlines) that a bulk --force-update introduces across 340+ other snapshots was reverted, so the diff here is only what actually changed. Tests: zellij-utils 471 passed, zellij-server 1499 passed. branding.rs carries its own tests, including one asserting no shipped default path contains the string "zellij". Verified live: sl0ppij creates /tmp/sl0ppij-1000 next to an existing /tmp/zellij-1000, and `sl0ppij list-sessions` reports none while a stock zellij reports three running sessions.