zyedidia
Using terminal clipboard triggers paste when cutting
I am using micro 2.0.13 and Ghostty 1.2.0 over a high-latency SSH connection. I am just tapping ctrl-x to cut, but every other time, it causes a paste.
The only configured setting is { "clipboard": "terminal" }.
https://github.com/user-attachments/assets/c91a9a33-1bb6-455c-a891-ff16a1b038aa
I did some debugging and it seems to only happen when terminalClipboard.read times out and returns an error. When the tcell.EventPaste event eventually arrives micro treats it as a regular paste event.
On Ghostty specifically you can avoid the timeout and thus the issue by setting clipboard-read = allow in ~/.config/ghostty/config. The default is clipboard-read = ask, but I think the problem is that by the time you manually allow it micro has already received an error as it only waits for 200ms.
Increasing the timeout would fix the issue on Ghostty, but it would essentially freeze the editor on terminals that don't support OSC52 clipboard. I guess we could have a list of terminals that are known to support OSC52 & prompt for confirmation, and have a longer timeout for them only? (Kitty, Ghostty, not sure if there are others)
On Ghostty specifically you can avoid the timeout and thus the issue by setting
clipboard-read = allowin~/.config/ghostty/config. The default isclipboard-read = ask, but I think the problem is that by the time you manually allow it micro has already received an error as it only waits for 200ms.
I actually already use clipboard-read = allow in my Ghostty config.
micro has already received an error as it only waits for 200ms.
Pinging the remote server shows ~270ms latency. Would that be causing the problem?
micro has already received an error as it only waits for 200ms.
Pinging the remote server shows ~270ms latency. Would that be causing the problem?
Yeah that would also do it. I guess the high latency use case means we should increase the timeout for all terminals that are known to support OSC52, not just the ones that prompt for confirmation.
Increasing the timeout timer only decreases the occurrence rate, but doesn't really solve the behavior.
Maybe we can mask the concrete "ghost" tcell.EventPaste, which is the answer to the GetClipboard()? 🤔
BTW:
In a slightly newer versions of tcell it was refactored to wait for its own 200ms^1 and in the current HEAD of upstream to return a concrete tcell.EventClipboard instead of tcell.EventPaste^2.
https://github.com/gdamore/tcell/blob/340fa4f8f86b00bada44cf10483a39b2162e44cb/_demos/clipboard.go#L110-L112
