在 tmux 中設置 xterm-keys 會影響 vim 中的 Shift-Enter
我在 tmux 中啟用
xterm-keys了正常的 xterm 鍵綁定，例如使用Ctrl 箭頭鍵移動整個單詞。但是，通過啟用
xterm-keys它會導致Shift-Enter在vim. 特別是，Shift-Enter在正常模式下按下會切換從游標位置開始的 13 個字母的大寫，而與單詞邊界無關。在命令模式下按下鍵會退出該模式，然後切換 13 個字母的大小寫。通常在 中vim，此按鍵的結果是向下移動一行（正常模式）或執行任何輸入的命令（命令模式），據我所知，這些是預設行為。我已經用空
.tmux.conf和.vimrc文件重現了這個效果，所以它不是其他配置設置的副作用。
您現在正在使用
F14½密鑰。你已經走進了哈利波特的世界，在 DEC VT 鍵盤上的和鍵
F14½之間有一個鍵。VIM 不熟悉這個世界。F14``Help
在 DEC VT 鍵盤上，如圖片中的 LK401（對於 DEC VT420），
F1用於F20生成輸入控制序列 (DECFNK) 的功能鍵從 11 到 34。額外的 DECFNK 數字對應於鍵盤上的物理間隙實際上不是鍵。一旦意識到這一點，這是很合乎邏輯的。（在進一步閱讀中有更多關於此的內容。）特別是，F14生成一個 DECFNK 26 控制序列並Help生成一個 DECFNK 28 控制序列。如果打開
modifyOtherkeysXTerm 中的選項，而不是為一大堆鍵盤鍵生成更常見的輸入控制序列，當按下修飾符時，XTerm 會在 DECFNK 27 上生成一大堆變體，即 和 之間的F14程式碼Help。這背後的想法是，TUI 程序可以區分這些密鑰的各種修改和未修改的使用，這是它通常無法做到的。該
Enter鍵通常會生成 ␍ 作為輸入，但在被 修改時生成 ␊ 時除外，在此模式下，當與其他 DECFNK 27;⎈ Control組合使用時會生成 DECFNK 27;2;13 ; M ;13 用於其他修飾符組合的序列。⇧ Shifttmux 中的
xterm-keys選項讓 tmux 明白這一切。它將這些控制序列辨識為輸入，並將它們作為輸入發送到被多路復用的終端。問題是很少有 Unix 和 Linux 工具真正正確地理解這些控制序列。為了正確處理終端輸入，需要一個 ECMA-48 控制序列解析器，它知道中間字元、參數字元、最終字元等。但是使用 libedit、ZLE 和 Readline 等庫的程序（包括 shell）；使用 ncurses 的程序；並且像 VIM 這樣的程序沒有 ECMA-48 控制序列解析器。（同樣，在進一步閱讀中有更多內容。）他們沒有正確處理實際的終端協議。
相反，他們擁有的是相當臨時的輸入處理程序，它們進行過於簡單的模式匹配。這意味著它們無法處理此處 XTerm 和 tmux 使用的形式的 DECFNK 序列。
完整拼寫的 DECFNK 27;2;13 是字元序列 CSI
27;2;13~。使用 ECMA-48 中的 7 位程式碼擴展可以生成 ESC[27;2;13~。VIM 沒有將其正確解碼為 ECMA-48 控制序列，誤解了終端輸入，並且13~控制序列尾部的字元最終具有您所看到的效果，即轉換 13 個字元的大寫。進一步閱讀
