tmuxで通常のxtermキーバインディングを有効にしましたxterm-keys。Ctrl - 矢印キー。
ただし、xterm-keysこれを有効にするとShift-Enter望ましくない結果が生じる可能性がありますvim。特に、Shift-Enter通常モードで押すと、単語の境界に関係なく、カーソル位置で始まる13文字の大文字と小文字が切り替わります。コマンドモードでキーを押すとモードが終了し、13文字の大文字と小文字が切り替わります。通常、vimこのキーを押すと1行下に移動するか（通常モード）、入力したコマンドが実行され（コマンドモード）、私が知る限りこれがデフォルトの動作です。
.tmux.conf空の合計ファイルを使用して.vimrcこの効果を再現したので、他の構成設定による副作用ではありません。
答え1
今このキーを使用していますF14½。
あなたは誤って世界に入ってきました。ハリー・ポッター、DEC VTとキーボードのキーの間にキーがありますF14½。 VIMはこの世界が見慣れない。F14Help
図のLK401（DEC VT420の場合）などのDEC VTキーボードでは、ファンクションキーを使用して11〜34（DECFNK）番号の入力制御シーケンスを生成します。F1追加のF20DECFNK 番号は、キーが実際に存在しないキーボードの物理的な間隔に対応します。人々がこれに気づいたら、それは非常に論理的です。 （これについての詳細は、さらに読むことで確認してください。）特に、F14DECFNK 26制御シーケンスが生成され、HelpDECFNK 28制御シーケンスが生成されます。
XTermでこのオプションがオンのmodifyOtherkeys場合、修飾子が押されたときにキーボード全体のキーに対してより一般的な入力制御シーケンスを生成するのではなく、XTermはDECFNK 27で完全なバリエーション、すなわち間およびF14間隔コードを生成しますHelp。その背後にあるアイデアは、TUIプログラムが通常実行できないこれらのキーのさまざまな変更された使用と変更されていない使用を区別できることです。
このキーは、によって変更されたEnterときに␊が生成される場合を除き、一般に␍を入力として生成します。⎈ Control⇧ Shift中サイズ;13個の修飾語の異なる組み合わせのシーケンス。
tmuxのオプションをxterm-keys使用すると、tmuxはこれらすべてを理解できます。これはこれらの制御シーケンスを入力として認識し、それを多重化された端末への入力として送信します。
問題は、これらの制御シーケンスを実際に正しく理解するUnixおよびLinuxツールがほとんどないことです。端子入力処理適切に中間文字、パラメータ文字、最終文字などを理解するECMA-48制御シーケンスパーサーが必要です。ただし、libedit、ZLE、Readlineなどのライブラリを使用するプログラム（シェルを含む）、ncursesを使用するプログラム、VIMなどのプログラムにはECMA-48制御シーケンスパーサーはありません。 （詳細については後でお読みください。）実際の端末プロトコルを正しく処理できません。
代わりに、彼らが持っているのは、単純すぎるパターンマッチングを実行する、やや専門的な入力ハンドラです。これは、XTermとtmuxで使用されるDECFNKシーケンスを処理できないことを意味します。
DECFNK 27; 2; 13は文字シーケンスCSIとして完全に表記されています2 7 ; 2 ; 1 3 ~。 ECMA-48の7ビットコード拡張を使用すると、ESC [ 2 7 ; 2 ; 1 3 ~VIMはそれをECMA-48制御シーケンスに正しくデコードできず、端末入力を誤って解釈し、制御シーケンスの最後1 3 ~にある文字が結果として表示されます。 、13文字の大文字と小文字を変換します。