fix(wl-copy): assume mime text/plain, avoid clipboard manager refusin…#189
fix(wl-copy): assume mime text/plain, avoid clipboard manager refusin…#189dezza wants to merge 1 commit intotmux-plugins:masterfrom
Conversation
…g to paste If we don't supply a `text/plain` mime-type to `wl-copy` it will constantly assume types from text that can be problematic for some clipboard managers to handle. In this case clipboard manager such as https://invent.kde.org/plasma/plasma-workspace/-/tree/master/klipper Is strict and assume it is binary data (file copied) copied, which makes sense. I don't really see a need to assume anything but `text/plain` unless someone can come with a legit reason to oppose this PR.
|
Not sure but this might be related with this: But bottom line, it seems no one is really maintaining this anymore |
|
@nunojsa its a shame? Because I don't think there is an alternative is there? Has people moved? Should it be forked? |
Well, only if someone is willing to maintain it :) |
|
modern terminals have support for osc52, tmux https://github.com/tmux/tmux/wiki/Clipboard vim https://github.com/vim/vim/blob/master/runtime/pack/dist/opt/osc52/doc/osc52.txt what is very cool about this is- that you can use your terminals API > write to host clipboard - even if you are remote via ssh. How cool is that? No fiddling with x11 forwarding, no external binary calls - just portable via escape sequence and your favorite terminal - which standalone enables this with no dependencies except support from the software mentioned above. So I think this might be why this plugin is semi-abandoned. I uninstalled once I saw this was supported. |
2 participants
If we don't supply a
text/plainmime-type towl-copyit will constantly assume types from text that can be problematic for some clipboard managers to handle.Because
wl-copydetects viaxdg-mimeif it lacks a--typearg ( https://github.com/bugaevc/wl-clipboard/blob/master/src/util/files.c#L173 )In this case clipboard manager such as https://invent.kde.org/plasma/plasma-workspace/-/tree/master/klipper
Is strict and assume it is binary data (file copied) copied, which makes sense.
I don't really see a need to assume anything but
text/plainunless someone can come with a legit reason to oppose this PR.