Clipboard Manager

[kitknox]

Post any of your feedback on the new Clipboard Manager here. I’m still playing with some options, but for the next build I’ve made it so you can operate more of it entirely from the keyboard. I expect the sweet spot will be for iPad users where a system wide option is not available. There is some utility for iPhone, but I expect less frequent copy/paste going on. And then on macOS you just have other system-wide options, but it is still there for consistency.

[eejd]

I am in my first forays into rootshell, so I am not sure I fully have the baseline configuration complete and fully understood the UI interaction structure... but I could not get the clipboard to work at all. On an iPad Pro w/ Magic Keyboard, touching the text to copy and the magnifying-glass-like rectangular loop and central circle, followed with a delay by the selector color over a few letters near the circle produced almost always not the correct start letter (i.e. if I tried to select a shell command on an isolated line or a sentence embedded in a paragraph, often it was difficult to catch the first letter on the first try, and then, often had an extra space char captured at the end. However, even when the selection was complete, I was unable using any conforming iOS/macOS/Apple HUI guidelines compliment approach to copy the selected text. Clicking on the highlighted test revealed no 'copy' in the pop-down context menu. command-C on the keyboard did not copy the text. Toggling the clipboard manager / copy history did not seem to change the behavior.

[kitknox]

@eejd By default rootshell operates in a copy on select mode where the act of selecting text either with a long press and drag touch gesture or using the trackpad on your Magic Keyboard. (This can be disabled where you would need to use CMD-c or the copy button that auto appears after any text selection from touch already). Have you modified any of the defaults in terms of scroll mode or text selection?

Does this menu not appear for you :

The clipboard manager is for manager the history of items in your clipboard, but if you are ending up with issues in the text selection itself that sounds like a more fundamental gap that I haven't seen other reports of to date. rootshell also has support for getting the selection data via OSC 52 for integration with text editors, tmux, etc.

[eejd]

No modification made, but if it is copy on select, when I switched to another pane in tmux or another shell in rootshell, the 'paste' via touch and menu or 'command-v' did not have the selected text in the paste buffer.

[eejd]

Verified that I don't get that menu from a touch-hold or trackpad selection (again, default configs, other than having toggled history on and off--currently off. However, I did double check and this problem appears to be only in tmux sessions--not in ssh/local. The tmux config has standard default clipboard settings from the macports install.

[kitknox]

What app version and iPadOS version? This seems very odd.

[kitknox]

Also to confirm you aren't attempting to combine tmux's internal selection buffer along with a mosh session are you? The mosh-server terminal engine is incompatible with tmux and doesn't send the clipboard content to rootshell. It is one of many reasons that use of our tssh support is dramatically better. And with our tmux control mode support most users are better off not using the regular tmux modes anyway.

[eejd]

Ok, the tmux clipboard selection and paste work with the (non-Apple macOS and iOS HUI guidelines test selector) and paste works via tmux ]. However, the expected behavior on an iOS platform or macOS is that the clipboard would be shared with the iOS/macOS pastebuffer and would respond to ‘CMD-V’. Is there any reason this cannot be implemented? Also, while the test selector mechanism works, I find it a) more difficult to select the correct first character than the standard iOS approach when on an iPad (not yet tested on iPhone). And it often selects an adjacent line. Further, the ability to update the selection (via the standard iOS approach) seems not to work with this as expected. I think the original problems were with the mosh back end, I am now trying with both. However, as a Blink user, they do have the tmux/iOS pb and standard selector semantics working. I will continue to test, now trying both the mosh and tssh as I do want to move off of mosh, it was one of the reasons for being excited to see this project—as it seemed to be moving towards a more modern session management system and more iOS/macOS native feel. I haven’t been testing for the last week, will update with more experience/bugs as they arrise.

[kitknox]

Several things going on here. First let's start with just the tmux layer. If you are using standard tmux (non-control mode) in a TCP backed SSH session, or a tssh backed session, the text selection will depend on how you have tmux configured. If you have tmux configured with mouse mode enabled, we correctly honor that by default. In that mode all touch and mouse/trackpad controls are passed to tmux. tmux is responsible for doing text selection and clipboard management. In this mode it sends the OSC sequences back to rootshell for us to place clipboard contents on the clipboard, but the UX around text selection is exclusively implemented by tmux including how it allows for selection within its internal scroll back. I will have to go back and check, but my memory is that blink DOES NOT correctly honor that and bypasses it. To get our closest approximation of native text selection you need to have tmux mouse mode disabled, or configure rootshell to bypass it. We have a toggle for "Toggle Mouse Capture" as a hardware keyboard shortcut (CMD-shift-m), in the "Terminal" menu bar, and also available as a button in the on screen keyboard toolbar. When mouse capture is disabled client side you can select text and have it go directly into the system clipboard. This is important for a second scenario I will cover below.

The above is just tmux. If you are also combining tmux with mosh you now have 2 layers of terminal emulator before things hit rootshell. The OSC sequence to send to the clipboard emitted by tmux is NOT send by mosh-server to rootshell when tmux is in mouse mode. You select something with the crude tmux selection controls, and then can only paste with whatever you have bound tmux as the paste shortcut. You can bypass mouse capture mode as an alternative.

With all of that as background, moving from mosh to tssh gives you roaming and eliminates one of the terminal emulator hops. If you run regular tmux rootshell then gets the clipboard when in mouse capture mode. What rootshell has implemented now however is full tmux control mode ("tmux -CC" ie what originally only iTerm offered) which allows for your tmux panes to render as native rootshell tabs and splits. In this mode you get our full native scroll back and text selection. Note that when I say native the text selection is still our own custom loupe and controls as the ghostty rendered terminal doesn't provide any of this and I've done my best and mimicking the native controls. The drag handles etc I had to implement. If there are things that still don't feel native feel free to call them out and I can look at further optimizations. This is specifically the rectangular loupe mode.

Hopefully this wall of text makes sense. Even locally on macOS I now run tmux CC mode for all of my sessions in the local shell, and then over tssh for remote sessions. With multiple tmux controllers the vertical tab system really shines to keep things organized by group.