| Commit message (Collapse) | Author | Age |
|---|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A design doc, not an implementation: lets a project ship a layout that also tells
an agent what each pane is for.
The load-bearing decision is the boundary -- zellij carries one opaque string per
pane and never interprets it, pi owns the whole vocabulary. That keeps the fork
change to a single field threaded along the existing status_bar path, and lets the
vocabulary change without rebuilding zellij.
Records two findings that were checked rather than assumed, since both would
otherwise be discovered the expensive way: pane names cannot carry metadata (there
is no stable name field at runtime, and title is clobbered by whatever the program
sets), and the runtime query surface already exists (list-panes --json), so the
work is only to get the field into it.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
`status_bar_button_style "indexed"` renders `1:Approve 2:Reject` instead of
`[Approve] [Reject]`, so the bar doubles as a key legend for a harness that binds
alt+1..9 to the same actions.
A config option rather than a protocol field: whether the numbers mean anything
depends on what the USER has bound, not on what the program knows. It needs no
wire change and so no version bump, and the click report still carries the id --
never the index -- so a program is unaffected by which style is in force.
The style is threaded into layout_status_bar, the one function the renderer draws
from and the hit-test resolves against. That is what makes this safe: changing a
button's rendered width necessarily changes its clickable span too, verified by a
test asserting span width equals the drawn width and that every drawn column
resolves back, for both styles.
Also fixes the web client's Style construction to read the option from config
rather than defaulting it -- my first pass claimed that code had no pane_frames
config available, which was wrong; it uses it two lines further down.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A click target with no hover feedback gives you no way to tell what you are about
to hit, which matters more here than elsewhere because the buttons sit in a frame
row that is only one cell tall.
The hovered button is inverted rather than merely recoloured: swapping
fore/background reads regardless of which colours a theme uses, and makes "the
pointer is on THIS one" unmistakable next to its unhovered neighbours.
Tracked per client, because hover belongs to a pointer rather than to a pane --
with two users attached, one pointer must not light up the other's button. Stored
on the pane keyed by client id, which the frame renderer already has.
Updated before the action dispatch rather than in the hover action, because
motion over the ACTIVE pane is dispatched as SendToTerminal, not UpdateHover --
and the pane you are about to click a button in is usually the one you are
already in. Every other pane's hover for that client is cleared on each motion,
so moving between panes cannot leave a button lit behind.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reference for programs wanting to drive the bar: the OSC 5577 verbs, escaping
rules, click reports, limits, rendering behaviour, persistence, and the security
model.
Both worked examples were run against a real session rather than written from
memory, which caught four bugs in my own samples:
- the Python reader kept a trailing buffer window, so a processed report was
re-matched and every click fired twice
- it used tty.setraw, which also disables signals, leaving the sample unkillable
with Ctrl-C
- it exited via traceback and left the bar behind; both samples now clear it on
exit
- the shell reader echoed the report to the screen, and an `stty -echo` did not
help because bash's `read -n` saves and restores terminal settings around each
call. `read -s` is the fix.
Also verified and documented two behaviours I would otherwise have guessed at: a
BEL terminator works as well as ST, and the bar is not drawn when pane frames are
off (it lives in the frame row), reappearing when they return.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
In a collapsed (mobile) layout every stack member except the visible one is
suppressed, and the finder skipped suppressed panes outright -- so it could only
ever find the one pane already on screen, which defeats the point of having it
there.
Suppressed terminals are now listed and marked "(hidden)". Suppressed plugins
still are not: zellij:link and friends are deliberately invisible
infrastructure, and focusing one shows an empty pane. Unfiltering everything
listed it, which is how that distinction surfaced.
Needed no server work. Screen::focus_pane_with_id already locates the owning tab
via has_pane_with_pid, which includes suppressed panes, and calls go_to_tab; and
Tab::focus_pane_with_id tries focus_hidden_stack_list_member first. So selecting
a hidden stack member swaps it into view and selecting a pane in another tab
switches tab, both already handled by the host.
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Reaching the finder through a mode dance (leader, then session mode, then a
letter) is too many keys for something used constantly. Documents Ctrl-; as a
one-chord binding, and why: ';' has no control-code meaning, readline does not
bind it, and vim binds only bare ';' -- while plain ';' keeps typing normally.
Also records the tradeoff. Ctrl-; needs the kitty keyboard protocol to be
distinguishable from a plain ';', so it silently never fires on a terminal
without it. The combos that work anywhere are real control codes and are all
taken: Ctrl-\\ is SIGQUIT, Ctrl-] is vim's tag jump, Ctrl-_ is readline undo.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The finder always opened as a centred float with a frame. That costs its
margins (16% of columns, 28% of rows), a border, and on this fork the pane gap
as well -- on an 80x24 terminal leaving about 63x14 of the 80x24 available.
Rows are the scarce resource in a list, so most of the results were going to
decoration.
Below 100x30 it now takes the whole viewport and asks to be borderless, which
also drops the gap since this fork skips gap/padding for frameless panes. Above
that the centred float is kept, because it reads better when the space is
there.
The viewport is only knowable from TabInfo, so this re-evaluates on TabUpdate,
which is also how a terminal resize reaches a plugin -- switching modes live in
both directions. Re-applied only when the decision flips, so it does not fight
someone moving or resizing the pane by hand.
|
|
|
The pane finder was living in ~/dev with no version control at all, while
path-depending on this checkout's zellij-tile -- so the plugin and the binary
it must stay API-compatible with were maintained in two unrelated places, one
of them unversioned.
Its own workspace root rather than a member of zellij's: a non-root member has
its [profile] ignored, and opt-level="z" + lto + strip are what keep the wasm
small, which matters because the keybinding loads it with skip_plugin_cache and
recompiles on every launch. Staying independent also means carrying this crate
touches no upstream-tracked file, so it cannot conflict on a rebase.
install.sh no longer assumes ./target: this checkout's .cargo/config.toml sets
a shared build.target-dir, so the artifact lands in the repo's target dir
instead. It now asks cargo metadata where the build actually went, and fails
loudly rather than silently installing a stale wasm.
The zellij-tile path dep becomes relative, so the crate builds from any
checkout rather than only from /home/user/lol/zellij.
|
