| Commit message (Collapse) | Author | Age |
|---|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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 <baseline>/bun --version -> 1.3.14
qemu-x86_64 -cpu Nehalem <default>/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.
|
| | |
|
| | |
|
| |
|
|
|
|
| |
The tab harness cannot reproduce this (no rendering means panes_to_hide is
always empty), so the verification is a scripted pty that resizes mid-session.
Written down so it can be re-run rather than re-derived.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reported: only one tab for proj_a, where was proj_b? Both tabs existed --
list-tabs showed proj_b at position 1 the whole time -- but there was nothing on
screen to say so, because a generated session had NO tab bar and NO status bar.
sl0ppi passes its own `--layout` when creating a session, which replaces the
user's default layout, and the shipped config gets its chrome from
`layouts/default.kdl`'s `default_tab_template` (the zjstatus pane, which is what
draws the tab names). So a root with five projects looked exactly like a root
with one.
The obvious fix is to emit that `default_tab_template` into the generated
layout. It does not work: a templated tab comes back with `purpose=None`,
because the fork hangs a tab's purpose on the tab's root layout and templating
replaces it. Identity is load-bearing here -- with no purposes `sl0ppi ls` sees
no project tabs and `up` would happily create a second set of them. Caught by
checking list-tabs after the change rather than trusting the tab bar appearing.
So the template is INLINED instead: its body is taken, the project's panes are
substituted for its `children` node, and the result becomes the tab's contents.
The `tab` node keeps its own name/purpose/cwd, and the status bar comes along.
A template with no `children` node is skipped rather than mangled.
The extractor brace-matches by hand but respects strings and comments: a real
zjstatus template is full of `{index}` and `{name}` inside quoted format
strings, and counting those would truncate the block and emit a layout that does
not parse. It reads the live config, so a user's own default.kdl is honoured.
Verified on the test box: tab bar reads "1 proj_a 2 proj_b", tab purposes are
project:proj_a / project:proj_b, `sl0ppi ls` sees both, `up` still says "up to
date", and no phantom-client marker.
|
| |
|
|
|
| |
Both causes are now understood and closed, so the known-issue section becomes a
record of what it was and how it was proven fixed.
|
| |
|
|
|
|
|
| |
Records the exact function and the two defects in it (judging liveness on the
first message received, and deleting a live socket on a transient
ConnectionRefused), plus what the resize fix did and did not solve. The
handshake change is deliberately left unmade rather than rushed.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Three bugs found on a fresh Debian box, all of which made sl0ppi look broken
when the terminal underneath it was the problem.
1. JSON crash on startup. `action list-panes --json` against a session that has
died exits 0 with EMPTY stdout, and JSON.parse("") threw "JSON Parse error:
Unexpected EOF" at the user. Empty output is now "nothing", and genuinely
malformed output is reported with the command name and the offending text.
2. `up` silently resurrected. A dead-but-resurrectable session is not an empty
slot: `attach --create-background NAME` restores it from the serialised copy
and IGNORES --layout. The result was a root full of projects coming back as
plain shells with no agents and no purposes -- and the resurrected background
session then exited again within seconds. sl0ppi now refuses to guess and
explains the two real options (`up --fresh` to rebuild, `sl0ppij attach` to
restore it properly in a terminal). Verified on a clean slate that a fresh
`up` produces exactly the right panes: purpose='agent:main' held=true cmd='pi'.
3. The terminal's CLI actions are racy. Measured against a LIVE session on a
2-vCPU box: list-tabs and list-panes each fail ~60% of the time while the
session is detached, ~25% with a client attached, either with empty output or
"There is no active session!" (the action client consults
get_active_session() before it looks at -s). That is a defect in sl0ppij --
filed as a known issue -- but these are idempotent reads, so sl0ppi retries
them with backoff and distinguishes "the session is gone" from "the terminal
would not answer". `sl0ppi ls` went from failing most runs to 8/8.
Also:
- session creation returns before the server is registered, so `up` now waits
for readiness instead of racing its own next command
- UserError: actionable answers ("no project foo", "that session is a saved
dead copy") print and exit 1 instead of falling through to sl0ppij, which
buried the explanation and started a session nobody asked for
- `sl0ppi print <project>` implemented; it was referenced by the init template
and the design doc but did not exist
|
|
|
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.
|
