Minor correction/clarification: This is always due to a combined CSI and DCS escape sequence `\033[>0;95;0c\033P>|iTerm2
3.4.20\033\\` being sent in response to the CSI sequences `\033[>c` and `\033[>q`, since `\033[>c` and `\033[>q` are always sent in sequence.
I've removed some of the noise from the following tmux-server-*.log files.
This is a properly handled example:
1693018578.635438 /dev/pts/0: \033[>c
1693018578.635444 /dev/pts/0: \033[>q
...
1693018578.640830 /dev/pts/0: keys are 29 (\033[>0;95;0c\033P>|iTerm2 3.4.20\033\\)
1693018578.640834 /dev/pts/0: received secondary DA \033[>0;95;0c
1693018578.640849 /dev/pts/0: complete key \033[>0;95;0c 0xfe000000000
1693018578.640852 /dev/pts/0: keys are 19 (\033P>|iTerm2 3.4.20\033\\)
1693018578.640888 /dev/pts/0: received extended DA \033P>|iTerm2 3.4.20\033\\
This is an expired example, where the response gets appended to the command queue (effectively improperly handled, from a user perspective):
1693612605.769580 /dev/pts/1: \033[>c
1693612605.769603 /dev/pts/1: \033[>q
...
1693612619.256428 /dev/pts/1: keys are 29 (\033[>0;95;0c\033P>|iTerm2 3.4.20\033\\)
1693612619.256461 /dev/pts/1: next key is 29 (\033[>0;95;0c\033P>|iTerm2 3.4.20\033\\) (expired=0)
1693612619.256488 /dev/pts/1: next key is 28 ([>0;95;0c\033P>|iTerm2 3.4.20\033\\) (expired=0)
1693612619.256590 /dev/pts/1: next key is 27 (>0;95;0c\033P>|iTerm2 3.4.20\033\\) (expired=0)
1693612619.256703 /dev/pts/1: next key is 26 (0;95;0c\033P>|iTerm2 3.4.20\033\\) (expired=0)
1693612619.256843 /dev/pts/1: next key is 25 (;95;0c\033P>|iTerm2 3.4.20\033\\) (expired=0)
1693612619.256924 /dev/pts/1: next key is 24 (95;0c\033P>|iTerm2 3.4.20\033\\) (expired=0)
1693612619.257006 /dev/pts/1: next key is 23 (5;0c\033P>|iTerm2 3.4.20\033\\) (expired=0)
1693612619.257106 /dev/pts/1: next key is 22 (;0c\033P>|iTerm2 3.4.20\033\\) (expired=0)
1693612619.257195 /dev/pts/1: next key is 21 (0c\033P>|iTerm2 3.4.20\033\\) (expired=0)
1693612619.257285 /dev/pts/1: next key is 20 (c\033P>|iTerm2 3.4.20\033\\) (expired=0)
1693612619.257372 /dev/pts/1: next key is 19 (\033P>|iTerm2 3.4.20\033\\) (expired=0)
1693612619.257396 /dev/pts/1: next key is 18 (P>|iTerm2 3.4.20\033\\) (expired=0)
1693612619.257489 /dev/pts/1: next key is 17 (>|iTerm2 3.4.20\033\\) (expired=0)
1693612619.257582 /dev/pts/1: next key is 16 (|iTerm2 3.4.20\033\\) (expired=0)
1693612619.257671 /dev/pts/1: next key is 15 (iTerm2 3.4.20\033\\) (expired=0)
1693612619.257756 /dev/pts/1: next key is 14 (Term2 3.4.20\033\\) (expired=0)
1693612619.257837 /dev/pts/1: next key is 13 (erm2 3.4.20\033\\) (expired=0)
1693612619.257929 /dev/pts/1: next key is 12 (rm2 3.4.20\033\\) (expired=0)
1693612619.258031 /dev/pts/1: next key is 11 (m2 3.4.20\033\\) (expired=0)
1693612619.258122 /dev/pts/1: next key is 10 (2 3.4.20\033\\) (expired=0)
1693612619.258214 /dev/pts/1: next key is 9 ( 3.4.20\033\\) (expired=0)
1693612619.258303 /dev/pts/1: next key is 8 (3.4.20\033\\) (expired=0)
1693612619.258383 /dev/pts/1: next key is 7 (.4.20\033\\) (expired=0)
1693612619.258464 /dev/pts/1: next key is 6 (4.20\033\\) (expired=0)
1693612619.258548 /dev/pts/1: next key is 5 (.20\033\\) (expired=0)
1693612619.258636 /dev/pts/1: next key is 4 (20\033\\) (expired=0)
1693612619.258723 /dev/pts/1: next key is 3 (0\033\\) (expired=0)
1693612619.258811 /dev/pts/1: next key is 2 (\033\\) (expired=0)
1693612619.258834 /dev/pts/1: next key is 1 (\\) (expired=0)
1693612619.259242 input_key: \033
1693612619.259266 input_key: [
1693612619.259566 input_key: >
1693612619.259773 input_key: 0
1693612619.259985 input_key: ;
1693612619.260189 input_key: 9
1693612619.260420 input_key: 5
1693612619.260626 input_key: ;
1693612619.260825 input_key: 0
1693612619.261012 input_key: c
1693612619.261228 input_key: \033
1693612619.261249 input_key: P
1693612619.261432 input_key: >
1693612619.261621 input_key: |
1693612619.261814 input_key: i
1693612619.262017 input_key: T
1693612619.262217 input_key: e
1693612619.262405 input_key: r
1693612619.262608 input_key: m
1693612619.262797 input_key: 2
1693612619.262982 input_key:
1693612619.263163 input_key: 3
1693612619.263359 input_key: .
1693612619.263546 input_key: 4
1693612619.263746 input_key: .
1693612619.263945 input_key: 2
1693612619.264139 input_key: 0
1693612619.264333 input_key: \033
1693612619.264350 input_key: \\
Now that I understand the issue better after spending lots of time investigating it and the tmux source code, I know that nothing in that log will be surprising to you. However, I'd like to note that if I'm
experiencing this issue living in the middle of Manhattan, New York with a 5G mobile connection, then there are likely many others experiencing this same latency issue with even less reliable mobile connections, and it's likely that I'm just among the few that is reporting it. To the extent possible, a more robust solution or workaround would be greatly and sincerely appreciated.
Assuming that I don't compile from source (I have a lot of systems), my next step is to just incorporate a workaround in my tmux.conf, where I ignore similar input_key sequences. If you can point me (and others) to any examples, I'd appreciate it.
Thanks again!
Kind regards,
Jonathan