Brian Conway wrote:
> Spending a little time with 'cat -v', I ended up with the following
> non-.tmux.conf approach to making home/end happy in tmux with an
> otherwise-unmodified ksh shell:
>
> bind '^[[1~'=beginning-of-line
> bind '^[[4~'=end-of-line
>
> It doesn't appear to break normal xterm[-256color] use.
>
> These are still workarounds, of course.
Right. The following code exists in ksh/emacs.c:
/* more navigation keys */
kb_add(x_mv_begin, NULL, CTRL('['), '[', 'H', 0); /* home
*/
kb_add(x_mv_end, NULL, CTRL('['), '[', 'F', 0); /* end */
kb_add(x_mv_begin, NULL, CTRL('['), 'O', 'H', 0); /* home
*/
kb_add(x_mv_end, NULL, CTRL('['), 'O', 'F', 0); /* end */
We could continue adding a dozen more variations here, but I think there is a
larger problem.
I push a button on my keyboard. xterm gets a keycode, turns that into some
bytes (^[ [ H by the look of things), writes them into the pty, and then ksh
reads those bytes and does something interesting.
If I'm running tmux, xterm gets a keycode, turns that into some bytes, writes
them into the pty, tmux reads those bytes, for some reason changes them into
different bytes, then writes them into the ksh pty where ksh is confused by
them.
I do not understand why tmux is taking one set of perfectly good bytes and
turning it into a less good set of bytes.
