fix(ui): support clipboard paste in filter and command inputs#202
fix(ui): support clipboard paste in filter and command inputs#202nick4eva wants to merge 1 commit into
Conversation
Filter views only routed tea.KeyPressMsg to their textinput, so bracketed paste (Ctrl+Shift+V, tmux paste) was dropped and the textinput's built-in Ctrl+V never received its clipboard-read result. Forward paste and other textinput-bound messages to the focused filter input in the resource browser, service browser, log view, tag search view and multi selector, and accept tea.PasteMsg in command mode.
yimsk
left a comment
yimsk
left a comment
There was a problem hiding this comment.
Thanks for adding paste support and the accompanying tests. Overall, this looks like a good change.
Two things stood out while reviewing it:
- The clipboard result from Ctrl+V does not return to the command input in command mode.
- Mouse-wheel scrolling stops working in LogView while the filter is active.
Could you please take a look at these two cases?
| keyMsg, ok := msg.(tea.KeyPressMsg) | ||
| if !ok { | ||
| switch msg.(type) { | ||
| case tea.KeyPressMsg, tea.PasteMsg: |
There was a problem hiding this comment.
It looks like Ctrl+V still won't paste into the command input.
In Bubbles v2.1.0, the result of the clipboard read is returned as the unexported textinput.pasteMsg, rather than tea.PasteMsg.
Since this branch only forwards tea.KeyPressMsg and tea.PasteMsg to commandInput.Update, textinput.pasteMsg falls through to the current view and never reaches the command input.
One concrete way to address this would be to add a clipboard-read tea.Cmd under internal/clipboard that returns a public tea.PasteMsg on success, and intercept Ctrl+V in CommandInput.Update before delegating to textInput.Update. This would reuse the existing handleCommandModeMsg branch without depending on Bubbles' unexported message type.
It would also be helpful to add a test that executes the command returned by Ctrl+V and feeds its result back into App.Update.
|
|
||
| // Route paste and other textinput-bound messages to the active filter. | ||
| if v.filterActive { | ||
| return v.updateFilterInput(msg) |
There was a problem hiding this comment.
Mouse-wheel scrolling no longer works while the filter is active.
tea.MouseWheelMsg also reaches this branch and returns through filterInput.Update before it can reach the viewport. Before this change, mouse-wheel messages were passed to v.vp.Model.Update.
Could you route mouse-wheel messages to the viewport before this fallback? A regression test for scrolling while the filter is active would also be helpful.
2 participants
Filter views only routed tea.KeyPressMsg to their textinput, so bracketed paste (Ctrl+Shift+V, tmux paste) was dropped and the textinput's built-in Ctrl+V never received its clipboard-read result.
Forward paste and other textinput-bound messages to the focused filter input in the resource browser, service browser, log view, tag search view and multi selector, and accept tea.PasteMsg in command mode.
Closes #201