diff options
| author | user <user@clank> | 2026-08-08 22:19:25 +0200 |
|---|---|---|
| committer | user <user@clank> | 2026-08-08 22:19:25 +0200 |
| commit | 99af0bc5a8de8504d4f268b3c9e301e38ba12e14 (patch) | |
| tree | ab6c2f76a4e4c0316135d2f73060f757b94249f0 /example | |
| parent | sl0p: don't let hover steal focus while typing into a rename prompt (diff) | |
| download | sl0ppij-99af0bc5a8de8504d4f268b3c9e301e38ba12e14.tar.gz sl0ppij-99af0bc5a8de8504d4f268b3c9e301e38ba12e14.tar.xz sl0ppij-99af0bc5a8de8504d4f268b3c9e301e38ba12e14.zip | |
sl0p: fix getting stuck in rename mode (base_mode wiped)
Double-click-to-rename trapped the client: once in RenamePane, Esc and Enter
did nothing and there was no way out without killing the session.
Cause: Screen::change_mode() does `mode_info.base_mode = base_mode`, i.e. it
OVERWRITES the client's base mode with whatever it is handed. The
double-click path passed None, believing that meant 'leave it alone'. It does
not - ModeInfo::change_to_default_mode() is:
if let Some(base_mode) = self.base_mode { self.mode = base_mode; }
so a None base_mode makes leaving ANY temporary mode a silent no-op. The
legitimate caller in lib.rs passes Some(base_mode) from the session config;
this path had no equivalent.
Fix: Tab::client_base_mode() reads the client's existing base_mode (falling
back to the tab default) and the rename path passes it through, so entering
rename via the mouse leaves the return path exactly as the keybind does.
Added a test on ModeInfo pinning the trap itself: change_to_default_mode is a
no-op with base_mode None, and returns to the base mode when it is set. That
is the property that makes passing None dangerous, and it now fails loudly if
anyone assumes otherwise.
Immediate escape hatch for a session stuck on an older build:
zellij action switch-mode locked
(that goes through the server path, which sets base_mode correctly)
Baselines held: zellij-server 1429/30, zellij-utils 436/5.
Diffstat (limited to 'example')
0 files changed, 0 insertions, 0 deletions
