a sl0p.foo repository https://git.sl0p.foo/sl0ppi.git/atom/sl0pstatus/src/widgets/command.rs?h=main 2026-08-12T18:41:52Z 2026-08-12T18:41:52Z user user@clank 2026-08-08T21:54:38Z urn:sha1:f075ce0bd2ac29168e27596ab32abdfb6b2813ec Double-clicking a tab in the bar switches to it and drops into RenameTab mode, matching the double-click-to-rename we added for panes in the sl0ppij zellij fork. Enter commits, Esc cancels, exactly as the rename keybind does. Widgets are held behind &self and cannot keep click state, so double-click detection lives centrally in ModuleConfig::handle_mouse_action and is passed to Widget::process_click as a flag. THE TRAP, and the reason this is not a two-line change: handle_mouse_action also runs for Mouse::Release. A single click therefore arrives as LeftClick followed by Release at the SAME position. Counting releases would make every single click register as a double click, and resetting on release would mean a real double click never registers at all, since the release falls between the two clicks. Only LeftClick participates; Release neither counts nor resets. A completed pair is consumed, so a triple click does not fire a second rename. switch_tab_to() is called before switch_to_input_mode(), because RenameTab acts on the ACTIVE tab - renaming without switching first would rename the wrong one. Threshold is 400ms, the same one zellij uses for text-selection double clicks, so the bar feels consistent with the panes. Detection is extracted as register_click_for_double_click() so it can be tested without constructing a ModuleConfig. Tests cover: a real double click, the release-in-between regression, too-slow clicks, clicks at different positions, and the triple-click case. Upstream tests still pass: 25 total (20 upstream + 5 new). Note: this repo's .cargo/config.toml targets wasm32-wasip1 and runs tests under wasmtime, which is not installed here. Tests are run with `cargo test --target x86_64-unknown-linux-gnu` instead. 2026-08-12T18:41:52Z user user@clank 2026-08-12T18:41:52Z urn:sha1:dd1c0b2abb3734177fde75e88607dbe16f6357e9 Squashed import of dj95/zjstatus at 74f36b4 ("chore: bump version to v0.24.0"), the merge-base our fork was developed against. Found by the phase-3 smoke test: installing the tarball into a throwaway HOME and actually starting a session logged failed to load plugin from disk: '~/.config/zellij/plugins/zjstatus.wasm' (No such file or directory) config/layouts/default.kdl replaces zellij's stock tab-bar + status-bar with a zjstatus bar, so the status bar is load-bearing for the default layout -- and the .wasm in the live config dir turned out to be a *custom build*, not the upstream release. Dropping it as "a third-party blob no longer referenced" (see the config snapshot commit) was wrong: it was referenced from the layouts, which that commit did not check.