zellij: Can't select text with Zellij, Alacritty's URL recognition doesn't work

@imsnif I’ve started going down the rabbit hole of trying to understand how we could use terminfo to make sure clipboard interaction is supported.

There is a terminfo entry that should help us out, described at https://invisible-island.net/xterm/terminfo-entries.html#tic-xterm_pcfkeys:

# Ms modifies the selection/clipboard.  Its parameters are
#       p1 = the storage unit (clipboard, selection or cut buffer)
#       p2 = the base64-encoded clipboard content.
#

This later gets set to: Ms=\E]52;%p1%s;%p2%s\007.

The nvim docs also have some interesting information about $TERM and terminfo as well: https://neovim.io/doc/user/term.html.

The bad news is that as far as I can tell, some of the emulators (gnome-terminal, konsole) that don’t support OSC 52 are setting $TERM to xterm-256color, and at least on my system this includes the Ms capability. For example with gnome-terminal:

❯ echo $TERM
xterm-256color
❯ infocmp -x | grep Ms
	Ms=\E]52;%p1%s;%p2%s\007, Se=\E[2 q, Ss=\E[%p1%d q,

In all this I came across this in the notcurses 2.4.0 release notes:

The terminal is now extensively (but efficiently) queried on startup. Some properties are derived from the results.
    Numerous patches were submitted to upstream terminals to support this functionality.
    Eventually, this will be expanded to eliminate our reliance on TERM and dependence on terminfo.
    Eliminated the need to call notcurses_check_pixel_support() before using NCBLIT_PIXEL.

This made me curious, specially the comment here makes me feel like maybe the terminfo way is troublesome.

So like @futile also mentioned do you think we could use a simple heuristic in addition/as replacement for the Ms capability detection to see if OSC 52 is working? Something like write to clipboard, read back and check if value was written.

Good news here:

Problem solved!

I can now select text using the mouse only, and a right-click menu is also available with the command zellij options --disable-mouse-mode

Text is then copied with Ctrl + Shift +c

Other solutions:

• Run zellij options --mouse-mode false
• Add mouse_mode false to the config file config.kdl

Works with both gnome-terminal and terminator

As a reminder, here is my setup:

• Debian 11 with Gnome 3.38.5 Wayland
• zellij --version: 0.33.0
• gnome-terminal --version: GNOME Terminal 3.38.3 using VTE 0.62.3 +BIDI +GNUTLS +ICU +SYSTEMD
• xclip -version: 0.13

One single issue remains:

• Pasted text contains decoration coming from Zellig’s interface: each pasted line starts and ends with │, and empty space in Zellig’s window results in whitespace characters in pasted output (I can provide more details if you think it’s relevant)
• Related issue: copying text from a pane on the right also takes the content of the left pane

I’ll investigate that later. Thanks a lot, for zellij and the awesome documentation, cheers

I want to mention that holding shift in alacritty makes link highlightning / URL recognition work.

Is there a way to not need to hold shift to have a more “normal” selection behaviour? (I mean “normal” in the sense of not running zellij/tmux/etc, just running in a normal terminal).

Zellij is really awesome and I’d love to use it, but this text selection is something that gets in the way (for me at least).

Another possibility would be to read current clipboard contents, do the check, then restore it if successful.

Am I understanding correctly that you'd like to work on this? Yes, I’ll do some experimenting to see how viable this road is.

@leodamsky - cool, I’m happy copying works 😃

@leodamsky @TheLostLambda - we actually copied the copy-on-release behaviour from tmux. We might be able to leave the mark there (in addition to copying) but I don’t think it will be very helpful. The reason for this is that these marked cells aren’t actually marked by the terminal emulator (as would happen outside of Zellij). What happens is that Zellij changes their background to make them appear marked and then is able to copy their contents to the clipboard through the OSC signal I mentioned earlier.

So since the terminal emulator (gnome-terminal, Alacritty, etc.) doesn’t actually know which text is marked, we would have to implement ctrl-c (or whatever shortcut the OS uses) ourselves in order to mimic this experience. IMO this is a little overboard and very prone to bad UX (eg. how do we know exactly which shortcut one has configured for copy/pasting outside of Zellij? They differ by OS and are very much configurable).

Another option is to investigate if there’s an OSC (or other) signal that tells the terminal to mark a certain area on the screen. I started looking into this but couldn’t find anything (though I didn’t spend a very long time on this, tbh, since I’m a little swamped at the moment 😃 ). This will be kind of okay, but of course won’t work if one marks long text that exceeds the pane (eg. marking while scrolling up).

So - IMO the best way is to leave things as they are now and ideally communicate to the user somehow that the text was copied to the clipboard (quick status message on the bottom line?)

About URLs: I don’t have any useful input here. This would have to be investigated. Might be an additional OSC signal from what I could briefly glean investigating the other issues.

About scrolling inside vimtutor: I think this is a bug that will be solved by https://github.com/zellij-org/zellij/pull/624

Sorry for the brief answers. There are more than a few issues wrapped into this one bug and I have a lot on my plate in the next few days. In general I’d be happy to solve as many of these as we can. If someone’s interesting in doing some research on one/more of these, I’d be happy to provide guidance. Otherwise I’ll try to get to them in the coming weeks as I do another batch of compatibility bugs.

I’ve successfully copied text from Zellij with
Shift + Text selection then Ctrl + Shift + C

Thanks for the detailed information everyone!

Configuration

• Debian 11 + Gnome Wayland
• zellij --version: 0.33.0
• gnome-terminal --version:
  GNOME Terminal 3.38.3 using VTE 0.62.3 +BIDI +GNUTLS +ICU +SYSTEMD
• xclip -version: 0.13

Caveats

• Pasted text contains decoration coming from Zellig’s interface: each pasted line starts and ends with │, and empty space in Zellig’s window results in whitespace characters in pasted output (I can provide more details if you think it’s relevant)
• Related issue: copying text from a pane on the right also takes the content of the left pane
• There is a right-click menu in gnome-terminal, but launching zellij disables it. This could make things easier for newcomers

#996 has been merged, and allows configuring a command to pipe the selection into. This can be used with xcpli/xsel/wl-copy/pbcopy etc. as a workaround on terminals that don’t support osc52.

Thank for your efforts on this. It’s unfortunate that libvte won’t support OSC 52, as that in turn effects all libvte based terminal emulators (e.g., xfce4-terminal and terminator also do not actually copy the text). FWIW these emulators have the same issue under tmux (the somewhat hacky work around in tmux is adding custom bind-keys for mouse events to call xclip).

For those using libvte based terminals, my work around has been to hold shift while selecting text to bypass zellij (or tmux for that matter) which sends the selection through to the underlying terminal emulator. A downside is that it leaves the selection highlighted and doesn’t know about panes (https://github.com/zellij-org/zellij/issues/375), but a potential advantage is that it only copies the selection to primary clipboard (for use with middle-click / shift-insert) and can be copied to system clipboard manually with ctrl-shift-c or shift-right click menu, which lets you keep two things in the clipboard in lieu of an internal selection/clipboard manager.

I believe there is a way to toggle off mouse support in the configuration file (pinging the knowledgeable @a-kenji ), but it might be nice to have a flipped mode where you can hold shift to use the Zellij mouse support and have it disabled without shift

@tlinford - I don’t really want this to be an option, tbh. I think this is something Zellij needs to figure out on its own. It’s too much to expect a user to configure, I feel. We can probably figure out the terminal emulator from terminfo, but I’m not too sure about the being-in-an-ssh-tunnel sort of thing. Maybe @kunalmohan has an idea? (context for @kunalmohan: we want to be able to only interact with the clipboard if we are not in an ssh tunnel - I think you might have looked into something similar with recognizing ssh tunnels in the past but I’m not sure… do you have any ideas?)

Since Zellij is a terminal multiplexer and not a terminal emulation app, we can’t assume that the machine it’s running on is the same machine the user is on. A common use-case is for the user to ssh to a remote machine and start Zellij there. If in such cases we would interact with the machine’s clipboard, we would definitely not be doing the right thing.

If we detect that we’re running inside Gnome Terminal and then in that case interact with the clipboard, we can also potentially hit the case above. We would have to detect that we’re running inside a gnome terminal and not inside an SSH or some remote session tunnel (which I think is possible but am not 100% sure).

I get Gnome Terminal’s reasoning about not wanting to compromise the user’s clipboard even though I don’t agree with it personally. The same program that sends the OSC 52 can send a different string of VT instructions that would make the user think they need to type their root password. Why doesn’t it want to protect from that?

If gnome terminal’s decision is final, I’d be open to changing the message to something like “Unsupported terminal: can’t copy to clipboard - run Zellij without mouse support to avoid this” or something less wordy 😃 Either that or trying to implement the “running inside gnome terminal but not inside an SSH tunnel” solution.

@futile - I’m sorry you feel this way, but this really is a bug in gnome terminal itself: https://gitlab.gnome.org/GNOME/vte/-/issues/125

We can try to find workarounds for it, but it’s not really up to us.

Regarding alacritty url recognition, tmux with mouse mode enabled has the same problem.