sl0ppij.git/zellij-server/src/tab/mouse_handler.rs, branch main

sl0p: highlight the status bar button under the pointer

2026-08-12T13:50:04Z

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.

sl0p: clickable action buttons in the pane status bar

2026-08-12T13:18:33Z

Second slice of the status/action frame. A program declares buttons, and a click is reported back to it: printf '\033]5577;1;buttons;approve:Approve;reject:Reject\033\\' -> click -> program's stdin receives OSC 5577 ; 1 ; click ; approve ST The report is a FIXED format carrying only the id, never bytes the payload chose, and ids are restricted to [A-Za-z0-9_-]. The sequence that creates a button is in-band and untrusted -- `cat` of a hostile file emits it as readily as a cooperating program -- so a click that could send arbitrary bytes would let viewing a file inject into the stdin of whatever is running, a shell included. Labels are '%'-escaped since the wire format is ';'-separated, and both the button count and id length are capped because the list lives as long as the pane. Positions come from one layout_status_bar function that the renderer draws from and the hit-test resolves against. Computing that geometry twice is how the stacked-pane picker once selected the wrong pane; a test asserts every drawn column resolves back to the button drawn there, across 100 widths. Two things the drive caught that unit tests could not: - The first delivery path pushed onto grid.pending_messages_to_pty, which is only drained when the PANE produces output -- so a click on an idle program sat in the queue forever. The write now happens at the tab level, which owns the senders. - The hit-test derived the frame row from the pane's raw geometry, but this fork draws the frame inset by gap_offset, so with `gap 1` every click missed by one row. It now derives from the CONTENT rect, which is by definition the inside of the drawn frame and therefore the same columns the renderer lays out. Buttons serialise with the session like the status text, so a resurrected pane comes back with its buttons intact.

sl0p: separate the hover resize hint from the hover highlight

2026-08-12T12:09:21Z

Upstream's mouse_hover_effects governs two unrelated things: the frame highlight on hover, and the "Ctrl or to resize" hint. Its own comment in default.kdl admits as much. So silencing a beginner reminder you have outgrown also costs you a highlight that stays useful indefinitely. mouse_hover_help_text (default true) gates only the hint. One line in execute_send_to_terminal; the highlight is set in execute_update_hover and is untouched. Config-file only, deliberately. The option has no protobuf slot, so it does not cross the client/server IPC contract -- the roundtrip test asserts exactly that, with the fixture set to None and a comment explaining why. It still works from the config file because the server parses the file itself and Options::merge keeps the file value when the client sends None; a CLI flag would be silently ignored.

sl0p: click the picker's indicator row to expand a capped stack

2026-08-11T14:19:19Z

The cap made the picker a scrolling viewport -- everything stays reachable by moving focus -- but there was no way to see the whole stack at once. Clicking "+N more" expands it to every member; the indicator becomes "- fewer" and collapses it again. Collapse gets its own label because an invisible way back out is not an affordance. Hangs off the indicator row because that row is already reserved, already rendered, and resolves to no member, so it is free real estate. It is also why this needs no new keybinding: mouse handling is entirely server-side, while Action is a protobuf enum we cannot extend without protoc. A click rather than hover, as expanding changes the reserved row count and so resizes the visible pane's PTY -- acceptable once per deliberate click, not on every mouse move. All three consumers of the row -> member mapping (renderer, reserved-row budget, mouse hit-test) now go through stack_list_window_for, so expansion cannot desync them the way the cap desynced the hit-test in 844617b4.

sl0p: preview pane reordering live while dragging

2026-08-08T21:32:35Z

Dragging showed only a green border on the target. The swap is now applied as you drag, so the real layout IS the preview and releasing just keeps it. Dragging elsewhere undoes it and previews the new arrangement; dragging off all panes restores the original. Because swap_panes is symmetric, applying it twice is the identity, so 'undo the preview' is just the same call again. Drop needs no work at all now - the swap already happened - which also removes the old drop-time swap. THE TRAP, which a naive version hits immediately: once the swap is applied the dragged pane sits under the cursor, so the next motion computes the dragged pane as its own target, undoes the swap, which puts the original pane back under the cursor, which re-applies it - oscillating on every motion event and spamming both PTYs with resizes. Avoided by treating two cases as 'the layout already shows what you would get' and doing nothing: - the cursor is over the dragged pane, wherever the preview has moved it; - the cursor is over the pane it is currently swapped with, which after a preview sits at the dragged pane's original position. So a swap is only re-applied when the cursor reaches a THIRD pane, which also keeps PTY resizes down to one pair per target change rather than per event. The dragged pane is kept highlighted rather than the target, so it stays identifiable while the layout moves around it. Note: the state machine lives in the executor and needs a real Tab, so it is reasoned through in the commit and README rather than unit-tested; the decision-level tests cover only which action is produced. Baselines held: zellij-server 1441/30.

sl0p: highlight the drop target while dragging a pane

2026-08-08T21:25:55Z

Dragging a pane by its title was blind until release. The pane a drop would land on is now highlighted with the theme's frame_highlight colour. Reuses the existing hover highlight rather than adding a second highlighting mechanism, but sets tab.mouse_hover_pane_id directly instead of going through execute_update_hover, which is gated on the mouse_hover_effects option. During a drag this is essential feedback rather than decoration, so it must not be switchable off. The pane being dragged is deliberately NOT highlighted when hovered: dropping onto itself is a no-op, so showing no highlight is the honest signal that releasing there changes nothing. The highlight is cleared on drop, so a completed drag does not leave a pane looking hovered. Baselines held: zellij-server 1441/30.

sl0p: rearrange tiled panes by dragging their title bar

2026-08-08T21:11:13Z

Dragging a tiled pane by its title bar and dropping it on another pane swaps the two. Previously the only way to rearrange panes was MOVE mode. The underlying operation already existed: the directional move_pane_* functions are all the same geometry swap, differing only in how they pick the other pane. Extracted as TiledPanes::swap_panes(a, b) so a pane can be swapped with an arbitrary target - the one a drag was dropped onto - which also de-duplicates what was four copies of the same swap. Gesture: the title row EXCLUDING its corners. Corners stay resize handles, so two-axis resize from the top is preserved. Plain top-edge resize is gone and costs nothing: every boundary is shared, so the boundary above a pane is the bottom edge of the pane above and can be dragged from there. A pane at the top of the viewport has the screen edge above it, which was never resizable. Ordering in determine_mouse_action matters three ways: - an in-progress drag is checked FIRST, so motion cannot be reinterpreted as text selection or a resize; - the drag check sits AFTER the double-click check, so the second click of a rename is not swallowed; - and BEFORE the resize branch, which would otherwise claim the title row. Two behaviours had to be preserved deliberately: - Dropping a pane on itself is a no-op, which is what keeps a plain click and a double-click working on the title bar. - Starting a drag focuses the pane. Pressing a title used to start a resize, which focused it as a side effect; without this a plain click on the title would do nothing at all. Stacked panes are excluded from the handle. Their title row is the affordance for focusing/expanding a stack member, and intercepting it broke focus_stacked_pane_under_flexible_pane_with_the_mouse - caught by the suite, not by hand. Baselines held: zellij-server 1440/30 (the 30 are pre-existing).

sl0p: route mouse rename through the server, fixing stuck rename mode

2026-08-08T20:23:41Z

Enter/Esc still did not leave rename mode after entering it by double-click. The previous attempt fixed a real trap (a None base_mode makes change_to_default_mode a silent no-op) but not this one. The actual cause: zellij tracks the client's input mode in TWO places. - Screen's ModeInfo, which drives what is rendered. - SessionData::current_input_modes on the server, which is what ROUTES key input to the right handler. The double-click path sent ScreenInstruction::ChangeMode directly, so only the first was updated: the rename prompt appeared and accepted text, while the server still interpreted keys in the previous mode - so Enter and Esc were never treated as rename-mode keys and there was no way out. Action::SwitchToMode (the rename keybind) sends ServerInstruction::ChangeMode instead, and the server handler updates current_input_modes AND derives base_mode from the session config before forwarding to Screen. The mouse path now sends exactly that, so it is the same code path as the keybind rather than an imitation of it. Tab::client_base_mode is dropped: the server supplies base_mode correctly, so it is no longer needed. Lesson worth keeping: 'send the instruction the existing feature sends' beats reconstructing its effects downstream. Both bugs here came from entering the system one layer too low. Baselines held: zellij-server 1429/30.

sl0p: fix getting stuck in rename mode (base_mode wiped)

2026-08-08T20:19:25Z

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.

sl0p: don't let hover steal focus while typing into a rename prompt

2026-08-08T20:08:09Z

Reported after double-click-to-rename landed: rename one pane, then hovering over other panes puts them in 'edit title' state too. Cause is focus_follows_mouse, not the rename itself. RenamePane is a CLIENT mode that acts on whatever pane is ACTIVE, so with focus-follows-mouse enabled every pane the mouse passes over becomes active and inherits the prompt. The double-click entry point just made it easy to hit, since you finish the gesture with the mouse sitting on a pane frame. Focus-follows-mouse is now suppressed for a client that is in a modal text-entry mode: RenamePane, RenameTab, EnterSearch or Prompt. Those all act on the active pane/tab, so moving focus underneath them is never what the user meant. Keyboard focus movement is untouched. Baselines held: zellij-server 1429/30.