GeorgeFilipkin / pulsemixer

I came across some minor but confusing glitch when using pulsemixer within tmux.

Steps to reproduce:

start tmux
start pulsemixer within a tmux window
press either Shift+Left or Shift+Right

Actual result: pulsemixer quits with status zero
Expected result: volume gets decreased/increased by 10%

I narrowed it down to this line:

Line 1442 in 71f15d0

sys.exit()

It enters the if block because c == self.ESC_KEY somehow. It seems like either tmux or curses is decoding the Shift key incorrectly.

(As a workaround, one can use H/L which are aliases for Shift+Left/Shift+Right.)

Had to add setw -g xterm-keys on to ~/.tmux.conf, otherwise Shift+Left and Shift+Right are getting eaten by tmux.

My guess is it has to do with $TERM. Tmux sets it to screen or tmux depending on the version (unless overwritten).

Normally Shift+Left generates just one number, 393. When $TERM is set to screen or tmux it generates a sequence of numbers, 27 91 49 59 50 68, every loop iteration screen.getch() gets the next number and when that number equals ord('q'), which is 27, pulsemixer exists.

Here is a similar issue #19

I can easily prevent pulsemixer from exiting by calling another getch before sys.exit, but not yet sure if I can get Shift+Left/Right to actually work as intended. For example I couldn't get vim's Shift+Left to work with TERM=screen. But in issue #19 the problem was with F1-3, which were also generating sequences, and F1-3 are working just fine in htop and vim with TERM=screen.

Had to add setw -g xterm-keys on to ~/.tmux.conf, otherwise Shift+Left and Shift+Right are getting eaten by tmux.

Setting setw -g xterm-keys on did not fix the issue for me.

My guess is it has to do with $TERM. Tmux sets it to screen or tmux depending on the version (unless overwritten).

My $TERM is set to xterm-256color automatically by tmux.

Normally Shift+Left generates just one number, 393. When $TERM is set to screen or tmux it generates a sequence of numbers, 27 91 49 59 50 68, every loop iteration screen.getch() gets the next number and when that number equals ord('q'), which is 27, pulsemixer exists.

I can confirm I'm getting the same sequence:

Shift-Right: 27 91 49 59 50 67
Shift-Left: 27 91 49 59 50 68

Here is a similar issue #19

I can easily prevent pulsemixer from exiting by calling another getch before sys.exit, but not yet sure if I can get Shift+Left/Right to actually work as intended. For example I couldn't get vim's Shift+Left to work with TERM=screen. But in issue #19 the problem was with F1-3, which were also generating sequences, and F1-3 are working just fine in htop and vim with TERM=screen.

FWIW, F1-F3 keys are working fine for me in pulsemixer.

I don't know if it's worth adding a conditional branch to match the sequence "27 91 49 59 50" then processing the last keycode properly. It might add unwarranted complexity especially since there is an easy workaround using H/L keys. I'll leave it up to you. Feel free to close this issue.

Thanks :)

a conditional branch to match the sequence

Pushed in just that. Can you please check if it's working for you?

@GeorgeFilipkin Awesome, it works perfectly. Thank you!

Conflict with tmux