From 9028f8175bda63d6a85e5a2dee2b4039020317a4 Mon Sep 17 00:00:00 2001 From: srdusr <99972264+srdusr@users.noreply.github.com> Date: Tue, 9 Jun 2026 14:35:00 +0200 Subject: Mouse support: wheel scroll everywhere, right-click context menus Explicitly requested - this is a real terminal app meant to work in any terminal (the name is a naming convention, not a tmux runtime dependency), and should be genuinely mouse-driven, not keyboard-only. Enabled via tea.WithMouseCellMotion() (SGR mouse mode, the same protocol nvim and most modern TUI apps use); coexists with tmux's own mouse mode the same way it would for any other terminal app. Scope was decided by a real, verified library constraint, not convenience: bubbles/table exposes no way to learn its own scroll offset (confirmed by reading its source - no YOffset accessor, the rendered window comes from unexported fields via a second internal layer of viewport scrolling on top of that). Mapping a click's screen coordinates to a specific table row can't be done without reaching into that library's private internals, which this deliberately doesn't do - silently selecting the wrong row on a misjudged click is worse than not supporting precise click-to-row at all. What's shipped, the reliable subset: - Wheel scroll everywhere there's something to scroll: tables via the already-exported MoveUp/MoveDown (no scroll-state assumptions needed), viewports via their own native wheel handling (bubbles/ viewport already has this - nothing in the codebase was routing tea.MouseMsg to it yet), and vi-modal text editors via new viTextarea.ScrollUp/ScrollDown (bubbles/textarea has zero native mouse handling at all, confirmed the same way - feeds wheel events as repeated up/down keypresses through the same tested movement path h/j/k/l already use). - Right-click opens a context menu (cmd/mitmux/contextmenu.go) - a horizontal strip taking over the status/help line, the same "replace the bottom of the screen" pattern confirmPrompt and the export/import prompts already use, rather than a floating popup positioned at the click (lipgloss/bubbletea have no compositor for splicing an overlay into an arbitrary screen position - not worth building just for this). Wired into every list-based view: history (view/repeater/intruder/flag-unflag/delete), rules (edit/enable-disable/delete), scope (enable-disable/delete). Menu items ARE reliably clickable, unlike table rows - the menu renders its own strip, so every item's width is fully known rather than hidden behind a library's unexported scroll state. Navigable by mouse click or j/k/arrows+enter; esc or right-clicking again dismisses. Deferred, not silently dropped: click-to-select-a-different-row (same scroll-offset limitation), and click-to-switch-pane-focus in Repeater/ Intruder (tractable via the same Y-coordinate math WindowSizeMsg already computes, just not done yet - keyboard tab already covers it, so lower priority than what shipped). Verified live in tmux by injecting real SGR mouse escape sequences directly into the pane (tmux send-keys -l with hand-built ESC [ < Cb;Cx;Cy M/m sequences, since tmux has no built-in "synthesize a click" primitive) against a running daemon with real captured entries: wheel-down/up on the history table correctly moved the selected-row highlight (confirmed via ANSI-aware capture, not just "no crash"); right-click opened the menu with the right actions; clicking directly on a computed menu-item position correctly triggered that exact action (clicked "delete", saw the correct entry's ID in the resulting confirm prompt); keyboard navigation inside the menu moved the highlight correctly; esc and a second right-click both dismissed cleanly with no side effects; wheel events in Repeater's text pane and Detail's viewport caused no crash and left vi-mode state intact; an empty rules table's right-click correctly no-opped; adding a real rule then right-clicking and clicking "disable" correctly toggled it off (confirmed via the rendered checkmark disappearing). go build/vet/gofmt/test/mod tidy all clean. --- PLAN.md | 75 +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 75 insertions(+) (limited to 'PLAN.md') diff --git a/PLAN.md b/PLAN.md index 0d1d52e..fe55cf8 100644 --- a/PLAN.md +++ b/PLAN.md @@ -436,3 +436,78 @@ support. No code needed here, just documented clearly in the README's Quick start (previously this was implied but never actually spelled out for a phone/tablet setup, which is a real, common daily workflow this tool hadn't explicitly walked through before). + +## Mouse support + +Explicitly requested - this is a real terminal app meant to work in any +terminal (not tmux-only; the name is a naming convention, not a runtime +dependency), and should be genuinely mouse-driven, not keyboard-only. +Enabled via `tea.WithMouseCellMotion()` (SGR mouse mode, the same +protocol nvim and most modern TUI apps use) - coexists with tmux's own +mouse mode the same way it would for any other terminal app, no +mitmux-specific code needed for that part; documented clearly instead +(README's new Mouse section) since it does need tmux's own `set -g +mouse on` to forward events at all. + +Scope was decided by a real, verified library constraint, not +convenience: bubbles/table exposes no way to learn its own scroll +offset (confirmed by reading its source - no `YOffset` accessor, and +the rendered window is computed from unexported fields via a second, +internal layer of viewport scrolling on top of that). Mapping a click's +screen coordinates to a specific table row therefore can't be done +without reaching into that library's private internals, which this +deliberately doesn't do - silently selecting the wrong row on a +misjudged click is worse than not supporting precise click-to-row at +all. What's actually shipped, chosen to be the reliable subset: + +- Wheel scroll everywhere there's something to scroll - tables via + `MoveUp`/`MoveDown` (exported, no scroll-state assumptions needed), + viewports via their own native wheel handling (bubbles/viewport + already has this, just needed `tea.MouseMsg` routed to it, which + nothing in the codebase was doing yet), and vi-modal text editors via + new `viTextarea.ScrollUp`/`ScrollDown` (bubbles/textarea has *zero* + native mouse handling at all, confirmed the same way - the value here + is feeding it as repeated up/down keypresses through the same tested + movement path h/j/k/l already use, not reimplementing cursor math). +- Right-click opens a context menu - a horizontal strip taking over the + status/help line (cmd/mitmux/contextmenu.go), the same "replace the + bottom of the screen" pattern confirmPrompt and the export/import + prompts already use, rather than a floating popup positioned at the + click. That's also a deliberate simplification: lipgloss/bubbletea + have no compositor for splicing an ANSI-styled overlay into an + arbitrary screen position, and building one just for this would be a + lot of new, fragile machinery for what's fundamentally a nice-to-have. + Wired into history (view/repeater/intruder/flag-unflag/delete), rules + (edit/enable-disable/delete), and scope (enable-disable/delete) - + every list-based view. Menu items ARE reliably clickable, unlike table + rows: the menu renders its own strip, so every item's on-screen width + is fully known rather than hidden behind unexported scroll state. + Navigable by mouse click, or j/k/arrows + enter; esc or right-clicking + again dismisses without acting. + +Deferred, not silently dropped: click-to-select-a-specific-different- +row in a table (blocked by the same scroll-offset limitation above), +and click-to-switch-pane-focus in Repeater/Intruder (would need +Y-coordinate matching against the exact same split-point math +WindowSizeMsg already computes - tractable, just not done yet, lower +priority than what shipped since keyboard `tab` already covers it). + +Verified live in tmux by injecting real SGR mouse escape sequences +directly into the pane (`tmux send-keys -l` with hand-built `ESC [ < +Cb;Cx;Cy M/m` sequences - there's no built-in "synthesize a mouse +click" primitive in tmux's own tooling) against a running daemon with +real captured entries: wheel-down/wheel-up on the history table +correctly moved the selected-row highlight (confirmed via ANSI-aware +capture, not just "no crash" - the actual background-color-highlighted +row changed), right-click opened the menu with the right actions, +clicking directly on a specific menu item (computed its expected X +position from the same label-width logic contextMenuAt uses) correctly +triggered that exact action - confirmed by clicking "delete" and seeing +the correct entry's ID in the resulting confirmation prompt - keyboard +navigation (j) inside the menu moved the highlight correctly, esc and a +second right-click both dismissed cleanly without side effects, wheel +events in Repeater's text pane and Detail's viewport caused no crash +and left vi-mode state intact, an empty rules table's right-click +correctly no-opped (no crash, no menu), and adding a real rule then +right-clicking it and clicking "disable" correctly toggled it off +(confirmed via the rendered checkmark disappearing). -- cgit v1.2.3