search

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

Use tmux-specific `ssh-tty` #28

Open hartikainen opened 1 year ago

hartikainen commented 1 year ago

Hey,

I recently had several cases where my SSH_TTY environment variable was unset in my emacs even though tmux show-environment SSH_TTY was correctly pointing to /dev/pts/0. This breaks clipetty-cut and thus also interprogram-cut-function. I wonder if we should be using clipetty--get-tmux-ssh-tty instead of (getenv "SSH_TTY" (selected-frame)) when tmux is available? Here's what I saw when debugging this:

(getenv "TMUX" (selected-frame))
"/tmp/tmux-861335/default,9658,0"
(getenv "TERM" (selected-frame))
"dumb"

;; on a working emacs window
(getenv "SSH_TTY" (selected-frame))
"/dev/pts/0"

;; on a broken emacs window
(getenv "SSH_TTY" (selected-frame))
nil

(let ((tmux    (getenv "TMUX" (selected-frame)))
        (term    (getenv "TERM" (selected-frame)))
        (ssh-tty (getenv "SSH_TTY" (selected-frame))))
        (clipetty--tty ssh-tty tmux))
;; results in `/dev/tty` on a broken emacs session (i.e. when `ssh-tty` is `nil`)
;; results in `/dev/pts/0` on a working emacs session (i.e. when `ssh-tty` is `/dev/pts/0`)

I'm not sure if my suggested solution is the "correct" solution in general but I'm opening this in case someone else faces similar issues and to potentially discuss if there's a better fix to this. I guess the first question is why is my SSH_TTY unset under emacs even though tmux show-environment SSH_TTY is set and correct. Is this a common thing to happen or is there something weird in my setup?