Open randomizedthinking opened 7 months ago
I don't think mosh does any keycode translations at all. From my read of https://github.com/mobile-shell/mosh/blob/1105d481bb9143dad43adf768f58da7b029fd39c/src/terminal/terminaldisplayinit.cc the capability inspection doesn't do anything with keycode translations.
You are right that mosh does not do any keycode translation. I can use showkey -a
to verify that the keycodes of Home
are identical on both local and remote boxes.
It confused me. Since mosh now uses TERM=xterm internally, how can it handle different term setups without any such translation?
how can it handle different term setups without any such translation?
I believe the answer is "it doesn't". I'm actually a bit unsure why we haven't run into this before, because I use mosh regularly from rxvt-unicode-256color myself, and have never noticed an issue.
Also, there is something interesting about this issue. Home/End keys won't work under the shell command line, but they work in both vim and emacs. Not sure why both vim and emacs can process them properly.
The 2 keys also work fine in tmux sessions, but not outside of it.
I noticed that both Home/End keys are not working on shell command line under mosh. After fiddling around, the root cause per my investigation is due to the keycode translation between another term and mosh (xterm): Home key is defined as
^[[7
under urxvt. Yet internally, mosh uses xterm, so Home key is expected to be^[[H
.My speculation is that mosh does not do the correct job of translating Home keycode from rxvt-unicode-256color term to xterm correctly. I did the same test under tmux -- note tmux is running inside xterm. Again, the keycode translation is also incorrect from tmux-256color to xterm.
How to reproduce the issue:
mosh version: 1.4.0.