zellij-org / zellij

A terminal workspace with batteries included
https://zellij.dev
MIT License
21.33k stars 644 forks source link

Copy to system clipboard UX improvements #1018

Closed raphCode closed 2 years ago

raphCode commented 2 years ago

For me, it would be more intuitive with the current copy behavior to write to the primary clipboard, since every X app behaves like this: Only selecting text with the mouse, no keypresses leads to the text ending up in the primary buffer, where it can be conveniently pasted anywhere by middle-clicking. Zellij seems to behave the same way, since it automatically copies the text after finishing the selection. I actually never expected the "normal" clipboard to be populated, so until now, I assumed zellij clipboard support is broken.

Consider populating the X primary clipboard (make this an option?), and please adjust the statusbar message to include the clipboard where text is copied to. I even advocate for writing "copied to the system clipboard" to make clear there are no zellij internal copy/paste buffers going on like in tmux. I don't know yet how the situation on wayland is.

These issues are related to copy/paste, but I felt my request fits better in a dedicated issue: https://github.com/zellij-org/zellij/issues/627 https://github.com/zellij-org/zellij/issues/671

tlinford commented 2 years ago

I have to admit I'm not a big user of primary selection, but I totally get your point. In my case I probably would have been confused if the selection by default went to primary :)

Would setting both the primary selection, and clipboard make sense instead of having it configurable? (cc @imsnif )

In any case, I did a quick test, and there is one annoying thing for now when writing to primary - the selection gets set correctly, but pasting with middle click inside zellij does not work, and shift+middle click has to be used. This happens because mouse mode is intercepting the middle click, so it would be necessary to bind middle click to write out the current selection (probably using bracketed paste?)

imsnif commented 2 years ago

Maybe I'm missing something or just generally confused, but isn't this sort of thing out of our control whether we use OSC 52 or an external command (like the config option we just added)?

tlinford commented 2 years ago

with the external command, it's something that depends on the command, for example: `wl-copy -p' vs 'wl-copy'

with osc, it's something that we can control via the first param:

imsnif commented 2 years ago

Aha! Cool, thanks for the explanation.

So with the external command I guess that's up to the user. I don't have a strong opinion about which clipboard we should be using with OSC 52, but I do feel using both is not super nice UX-wise. Users who distinguish between them might not be happy about us overriding both...

How do these affect macos btw?

tlinford commented 2 years ago

Don't know about macos, maybe @jaeheonji can help us out?

jaeheonji commented 2 years ago

@tlinford

First of all, macOS also has external command like wl-copy. it's a pbcopy. But, The most important thing is that macOS doesn't have the concept of PRIMARY Selection. It uses Clipboard only by default. (the system itself has a similar concept, but this is for Cut-Paste)

So in general, other programs also simulate PRIMARY, but in the end this is the same as using Clipboard internally.

Another UX thing to consider is that users familiar with macOS don't use middle-click by default. Because the Magic Trackpad and Magic Mouse, which are basic components of the Mac, do not have a middle-click button. So it is usually known as re-mapping the middle-click on the keyboard through an external program.

Hope this helps 😄

lucasjinreal commented 2 years ago

Ubuntu can not copy, how to fix it? I hit this problem every single time switch a new terminal or switch a new system.......

mpenning commented 1 year ago

I still hit this bug in zellij 0.33.0.

Workaround: start zellij with zellij options --disable-mouse-mode

imsnif commented 1 year ago

@mpenning - please read the issue carefully, since you also commented in a different issue, I have a feeling you're not encountering this bug, which is about differentiating between clipboard types.