Eu habilitei xterm-keysno tmux para ter ligações de teclas xterm normais, como movimento de palavra inteira, usando as teclas de seta Ctrl .
No entanto, ao habilitá xterm-keys-lo, causa Shift-Enterefeitos indesejados no vim. Em particular, pressionar Shift-Enterno modo normal alterna a capitalização de 13 letras a partir da posição do cursor, independentemente dos limites das palavras. Pressionar as teclas no modo de comando sai desse modo e, em seguida, alterna a capitalização de 13 letras. Normalmente em vim, os resultados deste pressionamento de tecla são mover uma linha para baixo (modo normal) ou executar qualquer comando inserido (modo de comando) e, até onde sei, esses são os comportamentos padrão.
Reproduzi esse efeito com arquivos vazios .tmux.confe .vimrc, portanto, não é um efeito colateral de outras configurações.
Agora você está usando a F14½chave.
Você entrou no mundo de Harry Potter , onde há uma F14½tecla entre as teclas F14e Helpem um teclado DEC VT. O VIM não está familiarizado com este mundo.
Em um teclado DEC VT, como o LK401 (para um DEC VT420) na imagem, as teclas de função F1para F20gerar sequências de controle de entrada (DECFNK) numeradas de 11 a 34. não são realmente chaves. É bastante lógico quando se percebe isso. (Há muito mais sobre isso na leitura adicional.) Em particular, F14gera uma sequência de controle DECFNK 26 e Helpgera uma sequência de controle DECFNK 28.
Se alguém ativar a
modifyOtherkeysopção no XTerm, em vez de gerar as sequências de controle de entrada mais usuais para um monte de teclas do teclado, quando os modificadores são pressionados, o XTerm gera um monte de variações no DECFNK 27, o código para o intervalo entre F14e Help. A ideia por trás disso é que um programa TUI pode diferenciar entre os vários usos modificados e não modificados dessas chaves, o que normalmente não pode fazer.A Enterchave, que convencionalmente gera ␍ como entrada, exceto quando gera ␊ quando modificada por ⎈ Control, neste modo gera DECFNK 27;2;13 quando usado em combinação com ⇧ Shifte outros DECFNK 27; M ;13 sequências para outras combinações de modificadores.
A
xterm-keysopção no tmux faz com que o tmux entenda tudo isso. Ele reconhece essas seqüências de controle como entrada e as envia como entrada para os terminais que estão sendo multiplexados.O problema é que muito poucas ferramentas Unix e Linux realmente entendem essas seqüências de controle corretamente. Para manipular a entrada do terminal corretamente , é necessário um analisador de sequência de controle ECMA-48, que conheça caracteres intermediários, caracteres de parâmetro, caracteres finais e assim por diante. Mas programas (incluindo shells) usando bibliotecas como libedit, ZLE e Readline; programas usando ncurses; e programas como o VIM não possuem analisadores de sequência de controle ECMA-48. (Mais uma vez, há mais sobre isso em leitura adicional.) Eles não lidam com o protocolo de terminal real corretamente.
O que eles têm em vez disso são manipuladores de entrada bastante ad-hoc que fazem correspondência de padrões excessivamente simplista. O que significa que eles não podem lidar com sequências DECFNK na forma usada por XTerm e tmux aqui.
DECFNK 27;2;13 por extenso é a sequência de caracteres CSI
27;2;13~. O uso das extensões de código de 7 bits do ECMA-48 torna o ESC[27;2;13~. O VIM não decodifica corretamente isso como uma sequência de controle ECMA-48, interpreta mal a entrada do terminal e os13~caracteres na cauda da sequência de controle acabam tendo o efeito que você vê, de converter a capitalização de 13 caracteres.Leitura adicional