Open kswope opened 6 years ago
rpwoodbu
commented
6 years ago Try this with the "Mosh (dev)" version in the Chrome Web Store to see if the problem persists. It has a newer hterm (the shared terminal emulator), which may have solved the issue. I'm also going to push an even newer one tonight (will be in v0.5.5).
kswope
commented
6 years ago No success.
Just to clarify further.
Having this line in tmux.conf
set -g mouse on Somehow defeats the copy to clipboard action. ( This is a chromebook )
For example, I exited tmux (where I found no success). Now, outside of tmux, I can highlight text with the trackpad, and as soon as I release I get a scissors icon flash in the middle of the screen, and now I can paste anywhere.
As I mentioned earlier, this is not a problem with secure shell app.
Its my understanding that there are some obscure code sequences being sent from tmux to the remote client that activates the system clipboard. Maybe mosh is ignoring them and secure shell isn't.
ToKe79
commented
6 years ago AFAIK you have to disable the mouse control if you want to use mouse to select text when using tmux (and e.g. vim too, for that matter).
Disable mouse control in tmux:
prefix (e.g. Ctrl-B) followed by :, set -g mouse off, Enter
When you need mouse control again:
prefix (e.g. Ctrl-B) followed by :, set -g mouse on, Enter
Disable mouse control in vim:
ESC, :, set mouse=, Enter
When you need mouse control again:
ESC, :, set mouse=a, Enter
cnst
commented
2 years ago Do you have to manually disable and re-enable mouse support in tmux / emacs / vim each time you need to copy something into Chrome in ChromeOS on a Chromebook?
On MacOS, you can simply press the fn function key to avoid sending mouse events to tmux, and have them handled locally by the Terminal.app itself; else, you can also use tmux show-buffer | pbcopy to transfer the tmux buffer into the shared MacOS paste buffer.
In Cygwin on Windows, you can use /dev/clipboard to manage the clipboard, or the Shift key to have the mouse events handled locally instead of sending them to tmux.
Even Termux in Android has termux-clipboard-set, which appears to work even in ChromeOS, BTW (after the separate termux-api.apk is installed, in addition to the main termux-app.apk).
Is native ChromeOS, with either Crouton, or Crostini, really not capable of clipboard / paste-buffer management from the command line at all?
xclip and xclipboard in Linux, but they don't seem to work in Crouton when all I'm using is startcli, as there's no X server to connect to; in Crostini, xclip -out and xclip -in work by themselves, but don't seem to share anything with the main ChromeOS.wl-clipboard package, it doesn't work in Crouton, but in Crostini, only the wl-paste works with the ChromeOS buffer, the wl-copy seems to discard the data it collects.
I'd be the first to say this must be a screw up with my settings, but I have I have no problem on the SecureShellApp, just this app.
Start up mosh on chromebook, log in.
Look at prompt- select prompt with mouse, let go, I get a copy icon popup in middle of screen for a second. Now I can ctrl-shift-v and copy back to terminal.
Start up tmux, cant copy anything new, can only past what was copied from before.
I can repeat this procedure with SecureShellApp and have no problems,
Even funkier, I can start up a secure shell app, login, attach tmux, and it fixes the copy problem with mosh if I run them together.
EDIT:
This definitely has something to do with mouse mode ( if it isn't obvious by now ) It seems like secure shell app just has a little extra secret sauce that mosh doesn't have to kick off the copy, if I were to guess I think it happens right on mouse button release.