spudlyo / clipetty Goto Github PK

Describe the bug
When I SSH onto my Amazon Linux instance. If I open terminal emacs WITHOUT a tmux session, clipetty-kill-ring-save works as intended and sends the region to my system clipboard.

From that same SSH session, if I launch tmux and open terminal emacs, clipetty-kill-ring-save does not send anything to the system clipboard. I don't see anything in the *Messages* buffer that indicates any error. toggle-debug-on-error also doesn't trip anything.

This was working prior and I'm unsure what changed (no changes to tmux/emacs configs recently).

To Reproduce
From Ubuntu 20.04 ssh to an Amazon Linux 2 instance. Launch tmux from this ssh session and launch emacs. Attempt clipetty-kill-ring-save and observe the contents are not present in the system clipboard.

Expected behavior
I expect the region clipetty-kill-ring-save is called on to be available on the system clipboard.

** System Info (please complete the following information):**

• OS: Ubuntu 20.04.6 LTS, 5.15.0-92-generic
• Emacs Version: 27.2
• Terminal program: st
• Any terminal multiplexers in play: tmux 3.3a
• Local or remote (over SSH): Remote

Additional context
N/A

I couldn't copy long text on Kitty, while I could do on iTerm.
Is this related to #1? (Clipetty does not fully support Kitty's extended OSC 52 xterm protocol)

Example:

$ seq 0 10000 > long-file
$ emacs -nw long-file
$ # try to copy the whole buffer with `clipetty-kill-ring-save`

Thank you.

Describe the feature
It seems like copying fails if I try to copy over large number of lines, e.g. 100 lines. So I guess larger clipboard feature is not implemented for Alacritty.

According to the disscussion over here alacritty/alacritty#600. Large clipboard is supported in Alacritty. Would you mind take a look at it and see if we are able to support it?

Thanks!

To Reproduce
Basic copying steps.

Expected behavior
A clear and concise description of what you expected to happen.

** System Info (please complete the following information):**

• OS: Use mac ssh into linux
• Emacs Version: 26.3
• Terminal program: Alacritty
• Any terminal multiplexers in play: Tmux
• Local or remote: over SSH

Additional context
Add any other context about the problem here.

Describe the bug
On my company's desktop, there is a admin user controlled by my company called bobby.mcgee monitors users. /dev/pts/3 belongs to that user.

When I try to use clipetty, it pops

clipetty--emit: Opening output file: Permission denied, /dev/pts/3

Can we skip those output files does not belongs to the current user?

Notes: It probly will happen if two people ssh into a same machine.

To Reproduce

1. Maybe create a file belongs to another admin user.
2. ssh and use clipetty

Expected behavior
No permission error.

** System Info (please complete the following information):**

• OS: LInux
• Emacs Version: 26.3
• Terminal program: Alacritty
• Any terminal multiplexers in play: Tmux
• Local or remote (over SSH)

Additional context
Add any other context about the problem here.

Describe the bug
Recently, I updated my tmux to 3.3a which is the latest version from homebrew. It causes tmux showenv SSH_TTY prints nothing. I need to add -g in order to print SSH_TTY env properly.

To Reproduce
Steps to reproduce the behavior:

• Install tmux 3.3a
• try tmux showenv SSH_TTY and tmux showenv -g SSH_TTY

Expected behavior
As tmux updated it's shownenv command, we should add -g for tmux version > 3.3a

** System Info (please complete the following information):**

• OS: Linux, Ubuntu 18
• Emacs Version: 28.2
• Terminal program: Alacritty
• Any terminal multiplexers in play [GNU screen, Tmux]: tmux
• Local or remote (over SSH): ssh

Additional context
Add any other context about the problem here.

Clipetty depends on the SSH_TTY environment variable to determine if you're running on a local or remote host. This obviously doesn't work if you're logged in via Mosh.

I don't see any reason why we couldn't support Mosh, so let's make it work!

Hi! Amazing package! Thanks for pushing it out. :)

Is your feature request related to a problem? Please describe.

I was wondering how feasible it would be to go "in reverse", that is, copying from the system clipbord (say OSX clipboard) into my ssh->tmux->emacs session.

Thanks for reading!

Describe the bug
I'm using the newest Doom Emacs with clipetty enabled in a ssh terminal. The client is ITerm2 on Mac and the target ssh machine is a linux docker. And I use dtach for nohup.
When performing delete/copy, I got clipetty--emit: Opening output file: Permission denied, /dev/pts/3.

To Reproduce
Steps to reproduce the behavior:

1. from MAC ITerm2, ssh to linux docker.
2. start emacs with dtach -A /tmp/emacs emacs.
3. make some copy & paste under evil mode.

Expected behavior
no error report.

** System Info (please complete the following information):**

• OS: Linux, macOS
• Emacs Version 26.3
• Terminal program iTerm2
• Any terminal multiplexers in play dtach
• Local or remote (over SSH) ssh

Additional context
Add any other context about the problem here.

Clipetty works for me when I use it outside tmux, or under SSH and tmux, but not under tmux for a local system.

This occurs regardless of whether emacs is run as a daemon or regularly, in all terminals I've tried (kitty, ST, and alacritty) on Linux.

I've tried debugging in the failing case, where I'm using tmux locally.

In this call to clipetty-emit with the encoded string that it want to cut, which in the case is the text defun, (clipetty--dcs-wrap string tmux term ssh-tty) evaluates to the following:

and (clipetty-tty ssh-tty tmux) evaluates to "/dev/tty".

Not sure whether that's behaving as expected, but my clipboard doesn't end up receiving the cut.

When I run without tmux, (clipetty--dcs-wrap string tmux term ssh-tty) evaluates to "^[]52;c;ZGVmdW4=^G" and the clipboard does receive the cut.

st, mlterm also support osc 52. i just tried them.

Describe the bug
Currently, when (getenv "TERM") is called in clipetty.el, it will only ever return "dumb" due to how emacs is implemented.

To Reproduce
Run emacs -nw, call (getenv "TERM"), see the word dumb. This means clipetty does not correctly detect gnu screen, and does not emit the wrapped string correctly.

Expected behavior
Detect screen correctly.

** System Info (please complete the following information):**

• OS: linux
• Emacs Version: 26.3
• Terminal program: xterm
• Any terminal multiplexers in play: ssh screen
• Local or remote (over SSH): over SSH

Additional context
I'm not sure the best place to put it, but you should be using:

(getenv-internal "TERM" initial-environment)

To detect if you're running under screen.

Describe the bug
Clipetty is not working for me

To Reproduce
Start emacs -nw in xterm
Installed clipetty from Melpa from a clean Emacs configuration.
Enabled global-clipetty-mode.
Selected text and M-w or C-w
Try to paste anywhere, nothing shows up.

** System Info (please complete the following information):**

• OS: Centos 7
• Emacs Version: 26.3
• Terminal program: xterm
• Any terminal multiplexers in play: no
• Local or remote: Local

Additional context
I am not familiar with this OSC 52 mechanism.
Is there a specific setting I need to enable for xterm?
I can barely find any useful information online.

I am not familiar with elisp. Can you tell me how to configure Doom Emacs to make Clipetty work?

Thanks a lot!

Describe the bug
When Clipetty takes over the interprogram-cut-function it does not chain to the previous function that existed there. This means that it is incompatible with other minor modes that may bind to that function.

To Reproduce

• Activate a minor mode (like bodycount-mode) that uses the interprogram-cut-function.
• M-x clipetty-mode

Expected behavior
I expect bodycount-mode to still function, even though clipetty-cut is assigned to the interprogram-cut-function. Clipetty should chain to the old value of the interprogram-cut-function to ensure this happens.

While Clipetty is Kitty compatible, it would be great if it would chunk up very large OSC 52 payloads into multiple appends. This shouldn't be that hard, but we'd need a configuration flag to know that the underlying terminal is Kitty when running remotely.

Describe the bug
When I copy text in emacs while in a tmux session on a remote machine connected via ssh, there is a ~2 second lag.
If I'm doing this outside of tmux, but still on the same remote machine, there is no lag at all.

To Reproduce
ssh to remote server
start or attach to existing tmux session
open file with text in emacs
copy text (try to move cursor while this is happening to notice lag)

** System Info (please complete the following information):**

• OS: Linux
• Emacs Version: 28.2
• Terminal program: iTerm2
• Any terminal multiplexers in play: Tmux
• Local or remote (over SSH): remote over SSH

Additional context
This may have nothing to do with Clipetty, and if so then please forgive me. However, I'm hoping someone might have some advice 😄 Thanks for the help and wonderful package!

Describe the bug
When clipetty-mode is enabled running in terminal (tmux or not), (evil-paste-after) fails after (evil-yank-line). Instead of pasting the yanked line into the line below the point, it is pasted after the point.
It happens in MacOS (iTerm2) and Linux (Kitty). It doesn't happen in graphical mode.
It's intereting that right after the paste fails, if I undo the paste, yank the line again and paste it then it works. As soon as I move the cursor, next yank_line->paste fails, undo->yank_line->paste works, and so on.

To Reproduce
Steps to reproduce the behavior:
1- Run: emacsclient -nw ~/init.el
2- M-x clipetty-mode
3- In evil-mode: yy (over any line) and p ==> FAILS
4- u (undo) -> yy (yank-line) -> p (paste) ==> WORKS
5- move the cursor and repeat 3, 4 and 5, etc...
6- Disable clipetty-mode and then repeating 3, 4 and 5: 3 never fails, always behaves as 4.

Expected behavior
In terminal mode with clipetty-mode enabled (in tmux or not) evil-yank-line should be pasted below the point/cursor, not after the point/cursor

** System Info (please complete the following information):**

• OS: Linux and MacOS
• Emacs Version: 26.3
• Terminal program: iTerm2 and Kitty
• Any terminal multiplexers in play: doesn't matter, it happens within TMUX or in not multiplexed terminal.
• Local or remote: both

Additional context
It happens pasting within the same buffer or into diferent one.

This is a just a little annoyance compared with how usefull and convenient clipetty has been in my workflow this last week since I discovered it, so thank you very much for your work.

Describe the bug
After some researches, I finally got clipetty to work with xterm+tmux (Yay!)
But, I've noticed while it works with normal emacs -nw, it does not work if I start with emacs --daemon.

To Reproduce
Start emacs server in tmux.
Use clipetty to copy..

Expected behavior
Things copied to clipboard

** System Info (please complete the following information):**

• OS: Linux
• Emacs Version: 26.3
• Terminal program: xterm
• Any terminal multiplexers in play: tmux
• Local or remote (over SSH): remote through SSH