sl0ppi.git/FORKS.md, branch main

release: 0.1.9, with a bun that runs without AVX2

2026-08-13T20:51:59Z

The tarball shipped bun's default x64 build, which requires AVX2 -- so sl0ppi installed cleanly on a plain KVM guest and then died with "Illegal instruction" the first time anything ran pi. Known since 0.1.7 and carried as an open item; not something to ship a third time. packaging/fetch-vendor.sh now fetches bun-linux-x64-baseline.zip. Verified without needing such a machine, on an emulated CPU that has none: qemu-x86_64 -cpu Nehalem /bun --version -> 1.3.14 qemu-x86_64 -cpu Nehalem /bun --version -> Illegal instruction Also drops the installer's closing note about the status bar asking for permissions on first launch: shipped plugins are granted implicitly now, so the prompt it told people to expect no longer appears. (That text is baked into the 0.1.9 tarball; it is wrong but harmless, and corrected for the next one.) And gitignores *.core -- qemu writes one where you stand when it kills a target on an illegal instruction, and a 100MB core dump nearly went into this commit. 0.1.9 contains everything since 0.1.8: the split button actually visible and clickable where it is drawn, including on stacked panes; shipped plugins not asking for permission; the status bar as a framed box in the pane style with a new-tab button and margins matching the pane gap, collapsing to a single line in the mobile layout; and runtime tabs keeping a status bar without losing the purpose the CLI uses for identity.

sl0p(bar): draw the bar as a framed box, and a single line when collapsed

2026-08-13T18:54:29Z

Given three rows the bar now draws the same rounded box the panes do, so the bottom of the screen reads as one more pane instead of a strip of text under them. Given one row it stays the line it always was, which is what a terminal narrow enough to collapse the layout should spend on chrome. The height is the LAYOUT's decision, because a plugin cannot resize its own pane: - default.kdl defines the bar as a pane_template `sl0pbar` and places it at size=3; - default.swap.kdl defines tab_template "mobile" placing the same template at size=1, and the `stacked` swap layout -- what responsive_layout collapses to below responsive_min_cols -- uses it. That reuse works because zellij parses a layout and its .swap.kdl with the same parser, on purpose, "so that we can reuse assets (eg. pane and tab templates)". Otherwise the collapsed template would have to duplicate the whole 100-line zjstatus configuration, and the two would drift within a week. ModuleConfig::viewport is the one definition of where the content line lives: three rows or more and it is framed, fewer and it is not, plus the column the content starts at. Rendering and click routing both read it, so the frame moves the drawing and the hit-testing together -- a click on the new border hits nothing rather than the widget it sits above. Clicks now check the LINE too, which a single-line bar never had to. status-bar-live.py grew the other half of the feature: the borders must span exactly the columns the pane frames span with rounded corners at their ends, a click on the border must not make a tab, and after shrinking the terminal below the responsive threshold the bar must be one line with no box -- with its button still working. The collapse is real: the bar lands on the last row, which only happens if the swap layout actually switched. One test bug worth naming: locating the button with str::find gave a BYTE offset, and the box glyphs are three bytes each, so the click landed two columns right of the thing it found. Same trap the pane frame tests document.

sl0p(bar): a new-tab button, and margins that match the pane gap

2026-08-13T18:36:45Z

First pass of the status bar overhaul, in the zjstatus fork plus the layout that configures it. margin_left / margin_right: the bar is a full-width pane while every pane above it is inset by the pane gap, so its ends stuck out past every frame on screen. The margins are applied by rendering into an inset viewport (inset_state), which is the same thing click positions are translated by -- so what is drawn and what is clickable come from one definition. That is the split button's lesson applied before shipping rather than after. {new_tab}: a clickable button that opens a tab and focuses it, with no name and no cwd, i.e. exactly what the `n` binding in TAB mode does. Clicking a tab already switches to it and double-clicking renames it; making one was the hole in the strip. Rendering and hit-testing are the same measured string here, so the button covers exactly the columns it draws. Both keys are inert when unset, so an unmodified zjstatus config renders identically. packaging/checks/status-bar-live.py reads the bar off a real session and asserts it spans exactly the columns the pane frames span, clicks the + and expects one more tab, then clicks beside it and expects none. Confirmed by setting the margins to 0 and watching the span assertion fail: (0, 99) against the frames' (2, 97). The check counts painted cells rather than ink, because a bar segment begins with a padding space inside its coloured pill -- strip the colour and the left edge reads one column off, which is half the margin being measured.

build: ship sl0pstatus, and install every plugin the package carries

2026-08-12T18:46:39Z

Phase 3: `make package` now produces a tarball that provably works on a machine with no node, npm, bun or rust. Two bugs the clean-room test found, neither visible until a session actually started: - the default layout builds its status bar out of zjstatus, which we were not shipping at all (vendored as sl0pstatus/ in the preceding commits) - install.sh installed a hardcoded plugin list, so zjstatus.wasm would not have reached the config dir even once staged Also: layouts/*.kdl still pointed at ~/.config/zellij, missed by the rename pass because that pass only rewrote config.kdl. Verified end to end, from the tarball, in a throwaway HOME with node/npm/bun/ cargo shadowed by stubs that fail loudly if invoked: sl0ppij --version -> sl0ppij 0.45.0+sl0p1 pi --version -> 0.84.1 (on the bundled bun) pir --help -> ok sl0ppij -s realtest -> session starts under a pty, config "Well defined", fork pane titles render, both wasm plugins load, no errors beyond the first-run permission cache Artifact: sl0ppi-0.1.0-x86_64-linux.tar.gz, 83M, + .sha256.

build: scaffold versioning, docs and the packaging pipeline

2026-08-12T17:39:44Z

Adds the layer that makes this a distributable product rather than three directories: VERSION one sl0ppi version for the whole monorepo FORKS.md what each component is based on, and how to rebase the fork Makefile build / vendor / stage / package, plus dev-box helpers packaging/ fetch pinned payloads, assemble an install tree, install it docs/ architecture, the rename plan, the roadmap The self-contained runtime question is settled and verified: pi upstream builds its own release binary with `bun build --compile`, and a vendored bun runs the vendored pi dist unmodified, so the tarball carries bun + pi and needs no system node, npm or rust on the target machine. packaging/install.sh does a per-user install under ~/.local, never clobbers an existing config (writes .new alongside, or backs up under --force-config), and warns loudly when a stock zellij is present -- because until docs/rename.md is implemented the binary is still zellij underneath and would collide with it.