spudlyo / clipetty

Manipulate the system (clip)board with (e)macs from a (tty)
GNU General Public License v3.0
167 stars 13 forks source link

[BUG] Clipetty does not work with emacs server? #12

Closed Shooooooooo closed 4 years ago

Shooooooooo commented 4 years ago

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

Shooooooooo commented 4 years ago

It works with terminal emacs server or terminal emacs with tmux. But not when emacs server running in tmux.

spudlyo commented 4 years ago

Hi! I run Clipetty under tmux on a remote machine using --daemon myself, and this is definitely supposed to work.

So my guess is that Clipetty is unable to lookup certain environment variables it needs when you're running Emacs as a server.

Try using M-: (which should give you an Eval: prompt) and then eval the following:

(getenv "TMUX" (selected-frame)) (getenv "SSH_TTY" (selected-frame))

Let me know what you get for those both when Clipetty works for you, and when it doesn't.

Shooooooooo commented 4 years ago

I am not entirely sure why, but when I do (getenv "SSH_TTY" (selected-frame)) in the failing emacs, it shows nil. But, when I call (getenv "SSH_TTY") without the frame variable, it's showing the correct tty variable. EDIT: I have realized there the output of (getenv "SSH_TTY" (selected-frame)) varies depending on how the first frame is created. If I create the first frame using emacsclient -nw -c, then the function returns correct tty variable. If I create the first frame using emacsclient filename, then the function returns nil.

Shooooooooo commented 4 years ago

I am not sure whether this is a Emacs bug or not. I have also tried calling function (frame-terminal) inside the failing emacs frame. It prints out the correct SSH_TTY. May be this is a more reliable function to use?

spudlyo commented 4 years ago

For me, (frame-terminal) returns the Tmux TTY, and not the underlying SSH_TTY. We need the actual SSH_TTY in order to bypass Tmux and prevent it from gobbling up the OSC escape sequence.

I would try creating a shell alias for Emacs like:

alias emacs='emacsclient -c -a ""'

That will start the server the first time if it's not running, and if it is will connect. For me anyway, I can get at the SSH_TTY environment variable launching emacsclient that way.

Shooooooooo commented 4 years ago

I wanted to invoke emacs server using -a option, but I could not get it to work with other settings I have. Specifically, I am using chemacs https://github.com/hlissner/doom-emacs/blob/develop/docs/getting_started.org#install-doom-alongside-other-configs-with-chemacs It is a bootloader of emacs and it changes the emacs server directory. Anyway, I've modified my emacsclient wrapper so that it use the option -c when it creates the first frame. Everything works for me now. Yay~ Closing this issue. Thank you!

spudlyo commented 4 years ago

Glad that was all it took!