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

[leodamsky]

Basic information
Text selection quickly disappears, so I can't copy it. This also affects Alacritty's URL recognition (to be able to open a link with a mouse). Not reproduced with tmux.

Selection:
zellij-7.log
log.txt
Scrolling:
zellij-7.log
log.txt
URL recognition:
zellij-7.log
log.txt

zellij --version: 0.15.0
tput lines: 35
tput cols: 94
uname -av or ver(Windows): Darwin MacBook-Pro.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64

List of programs you interact with as, PROGRAM --version: output cropped meaningful, for example:
Basically, bare zsh + Alacritty.

alacritty --version: alacritty 0.8.0 (5ac8060b) (but is also reproducible in macOS terminal)
zsh: zsh 5.8 (x86_64-apple-darwin20.0)

Further information
Reproduction steps, noticable behavior, related issues etc

1. Open Alacritty or macOS terminal.
2. Run vimtutor.

Option 1:

1. Try to select text.
2. Notice the selection disappears on its own.

Option 2:

1. Hover the cursor on one of the links in vimtutor.
2. Notice that it's not recognized (highlighted) and can't be opened.

Option 3:

1. Scroll vimtutor's page with Trackpad (if it's important).
2. Notice it's not scrollable and the cursor is blinking.
3. Notice that scrolling with j k is lagging compared to bare Alacritty + zsh.

Recorded issues:

Selection: https://user-images.githubusercontent.com/23016452/126950272-f768b9f7-5ff5-4571-b580-9ecccc092a4a.mp4
URL recognition: https://user-images.githubusercontent.com/23016452/126950761-df818494-95ca-4fcd-8b87-0e342cf8f12c.mp4

[TheLostLambda]

I can second this. I get the same behavior with gnome-terminal. There was a version of Zellij with mouse support that allowed me to select text and keep it highlighted I believe, but now the selection instantly disappears (without copying anything to the clipboard)

[imsnif]

Gnome terminal doesn't support OSC 52 which we use to signal the terminal emulator it should copy text to the clipboard: https://gitlab.gnome.org/GNOME/vte/-/issues/125

As for Alacritty: we send the above signal as soon as one releases the mouse. Could it be that it gets copied to a different buffer?

EDIT:
for reference: https://en.wikipedia.org/wiki/Clipboard_(computing)#X_Window_System

[leodamsky]

@imsnif can confirm, the text is, in fact, copied as soon as the mouse is released. Sorry, I didn't expect this to be implicit. So, I can't only select the text but am able to copy it. Is this an expected behavior? (not to be able to select text) Just want to understand whether the issue remains relevant, and whether Option 2 and Option 3 can be caused by the same thing.

[TheLostLambda]

For what it's worth, I think we should leave the text selected if that is possible? It seems more intuitive and works around the problem people will have with Gnome Terminal (as I suspect it's a very large share of our users). Is something like that possible? The auto copy and deselect is convenient when it works, but maybe isn't the most friendly default?

[imsnif]

@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 #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.

[TheLostLambda]

Hmm, is it not possible for us to have things actually selected in the terminal for the single line case? Sometimes it's nice to mouse select a couple of words, even if I can't copy whole blocks. I'm not quite certain how this would work though.

[imsnif]

Hmm, is it not possible for us to have things actually selected in the terminal for the single line case? Sometimes it's nice to mouse select a couple of words, even if I can't copy whole blocks. I'm not quite certain how this would work though.

Have them appear selected? Sure. But the copying would have already happened on mouse release.
Have them selected? Not unless we find some signal that we can send the terminal to do that. That would require some research.

[imsnif]

Btw, as a workaround for gnome terminal we can interact with the system clipboard directly (which is what tmux does afaik). But that won't work through ssh sessions and such. And we'd have to be careful not to do unexpected things with it. Generally I'd recommend people who need this feature not to use gnome terminal, but maybe that's too harsh.

[tlinford]

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

[SuperSandro2000]

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

tmux swallows all escape sequences it does not know for whatever reason. I had the hope zellij does not do that.

[SuperSandro2000]

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

Maybe https://github.com/contour-terminal/contour#references or https://gist.github.com/egmontkob/eb114294efbcd5adb1944c9f3cb5feda can help you with this.

[futile]

Just ran into this with gnome-terminal; zellij v16.0 even says "Text copied to clipboard", but nothing is copied to the clipboard, which is rather unintuitive and misleading.

[imsnif]

@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.

[futile]

Thanks for the reply! :) Yeah, I read the discussion (and also the discussion on gnome terminal's side), and understand that it's because zellij uses OSC 52 which gnome-terminal doesn't implement, but (many?) other terminals do. Gnome terminal actually has sensible (although in no way absolute) reasons for not supporting OSC 52; It would allow remote ssh hosts to inject (or read, but that is independent) things into the user's clipboard (like rm -rf /*;) from what I understand.

Is there a reason to not first try something like xsel/xclip (which I think tmux also does?), and then fall back to OSC 52 (and maybe try checking the clipboard contents afterwards?)?

I think the fact that zellij says "Text copied to clipboard", when it really wasn't, could qualify as a bug. Maybe checking whether zellij runs inside gnome-terminal (and mouse-mode is on) could help to output "Can't copy text in gnome-terminal; see /use "?

[imsnif]

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.

[tlinford]

As a possible workaround, it may be worth offering the user an option to use a different clipboard mechanism?
Anyway here are a couple of ideas:

• integrate with the host clipboard with something like https://github.com/alacritty/copypasta, this should work on all terminal emulators, with the tradeoff of not being able to copy when running in remote sessions.

• support passing the selected text to xclip/wl-copy/pbcopy etc., but I'm not sure there is an advantage compared to above.

• attempt to detect whether the terminal emulator supports OSC52, and if not keep mouse mode disabled unless explicitly enabled. From some quick research I haven't found a reliable way to do this.

[imsnif]

@tlinford - we seem to be in sync both in our thoughts and in our timing ;P

[tlinford]

indeed 😄
if you think adding the option, something like clipboard_provider = terminal/host and choosing between osc52/copypasta based on that makes sense, I can try and figure that out soonish.
I guess it's still far from ideal, but it may be an improvement fro some people.

[imsnif]

@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?)

[kunalmohan]

@imsnif sorry, I haven't worked on this before and have no idea on how we should go about recognizing ssh tunnels.

[imsnif]

Thanks @kunalmohan - for some reason I remembered differently. So I guess this needs some research.

[tlinford]

@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.

[imsnif]

@tlinford - I really enjoyed reading your detailed research and learned quite a bit from it, thanks for that.

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.

The issue here is that we still won't be properly detecting SSH tunnels. But it seems like this is probably the best solution for now (or ever?) - so I'm definitely open to trying this out. We should have a config option to shut this off, because I imagine this might be annoying to some users ("why does Zellij override my clipboard every time I open it?!")

I'm also wondering if this can be done in a "tight" way that won't block Zellij on startup - but that's an implementation detail that I have confidence you can solve. :) Am I understanding correctly that you'd like to work on this?

[futile]

The issue here is that we still won't be properly detecting SSH tunnels. But it seems like this is probably the best solution for now (or ever?) - so I'm definitely open to trying this out. We should have a config option to shut this off, because I imagine this might be annoying to some users ("why does Zellij override my clipboard every time I open it?!")

Maybe only perform the check after the user has copied something (or tried to) from within zellij? That way it would be rather natural.

[tlinford]

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.

[imsnif]

I really like both these suggestions! Looking forward to the PR on this :)

[futile]

Thanks a lot @tlinford and @imsnif! :)

[tlinford]

Haven't been able to do much on this yet, but there is a probably big problem already with the approach we wanted to try, kitty by default only allows writing but not reading: https://sw.kovidgoyal.net/kitty/conf/#opt-kitty.clipboard_control

[imsnif]

Kitty is generally quite hostile to terminal multiplexers, so there's not a lot we can do. I'm good with supporting as much terminal emulators as possible and not letting it block us.

[JCallicoat]

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 (#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.

[tlinford]

#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.

[raphCode]

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

[acheronfail]

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).

[TheLostLambda]

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

[a-kenji]

@acheronfail
You can possibly set mouse_mode: false, that turns mouse mode off completely.

@TheLostLambda

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

Maybe? I think a good intermediate solution would be to be able to turn off zellij special handling of selecting and automatically copying text, so maybe adding to:

# Choose the destination for copied text
# Allows using the primary selection buffer (on x11/wayland) instead of the system clipboard.
# Does not apply when using copy_command.
# Options:
#   - system (default)
#   - primary
# copy_clipboard: primary

an option called -- disabled?

It would certainly be interesting to have the handling inverted and maybe that is a good option?

I think before that we also want to have the selection be able to persist the key release.

[tlinford]

@TheLostLambda

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

That would be neat, but unfortunately I don't think this is possible. Once mouse mode is enabled, the terminal emulator will only report mouse events instead of handling them, with shift as the way to bypass this and interact directly with the terminal emulator.

@acheronfail what would be a more "normal" selection behaviour that you would like to see? Keep the selection on mouse button release instead of automatically copying as @a-kenji suggested, and copy explicitly with an action?

[haoadoreorange]

Have them selected? Not unless we find some signal that we can send the terminal to do that. That would require some research.

This seems like a viable option, may be we should try to take a look ?

[imsnif]

This seems like a viable option, may be we should try to take a look ?

Sure, if you like. I'd start here: https://invisible-island.net/xterm/ctlseqs/ctlseqs.html
Try to get to a point where you echo one of these as an ANSI sequence (eg. echo -e "\033]11;?\033\\") and get your terminal to change the selection. I took a brief look and didn't find anything promising, but definitely didn't skim the whole thing.

[RoneoOrg]

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

[imsnif]

@RoneoOrg I just want to reiterate: using a terminal that recognizes mouse mode (eg. Alacritty, xterm, wezterm, foot, etc.) makes all these issues go away.

[RoneoOrg]

Thanks for the reply @imsnif !

gnome-terminal seems to handle mouse mode, as I'm able to select text, copy, paste, get a right-click menu, etc.. as long as I don't start zellij: in this case, I lose the right-click menu and text selection requires to hold the Shift key.

I must admit that I'm completely lost in the middle of the numerous actors involved (Desktop environment, Windows manager, Terminal, multiplexer..)

I've read this whole topic again, tested zellij with copy_command "wl-copy" and tried both gnome-terminal and terminator, and the same problems appear.

Which direction should I take, with Debian + Gnome Wayland as only requirements?

[imsnif]

gnome-terminal does not support OSC52 (that's what I meant by mouse-mode) which is the method Zellij uses to make copy/pasting work. We have no other way of telling your terminal eg. not to copy the pane-frames. This is the same with terminator. This is arguably a gnome-terminal/terminator problem and not a Zellij problem (we just don't have anything else to do about it - they're the ones who do not support this feature).

I'd recommend you opt to use a supported terminal: Alacritty, xterm, wezterm, foot, etc.

[RoneoOrg]

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

[imsnif]

Mate - I'm happy this works for you - but as I mentioned above: these issues will only be solved for you if you switch to another terminal emulator. Have fun otherwise.

EDIT: unless of course you use the workaround in our troubleshooting, then everything should work except ssh and possibly the right-click menu you mentioned.

[Jackman3005]

Besides the matter of copying/pasting on selection and how that works. Is there a way to get the Alacritty URL recognition to work within Zellij? It allows for really nice customization of which apps to open for different link types that I'd really like to be using within Zellij.

Maybe I have something setup incorrectly?

[Jackman3005]

Responding to myself after a bit more research. I first tried to create a binding that toggles mouse mode so I could turn it off when I wanted Alacritty hints to work and open urls. This works!

~/.config/zellij/config.kdl

keybinds {
    shared {
        bind "Alt m" { ToggleMouseMode; }
    }
    ...
}

But then after digging a bit more I came across the following note in the Alacritty documentation

Opening URLs with the mouse
...
If an application captures your mouse clicks, which is indicated by a change in mouse cursor shape, you're required to hold Shift to bypass that.

So yeah, this works as well and is most convenient 🎉