tmux에서 일반 xterm 키 바인딩을 활성화했습니다 xterm-keys.Ctrl-화살표열쇠.
그러나 xterm-keys이를 활성화하면 Shift-Enter바람직하지 않은 결과가 발생할 수 있습니다 vim. 특히, Shift-Enter일반 모드에서 누르면 단어 경계에 관계없이 커서 위치에서 시작하는 13글자의 대소문자가 전환됩니다. 명령 모드에서 키를 누르면 모드가 종료되고 13자의 대/소문자가 전환됩니다. 일반적으로 에서 vim이 키를 누르면 한 줄 아래로 이동하거나(일반 모드) 입력한 명령이 실행되며(명령 모드), 내가 아는 한 이것이 기본 동작입니다.
.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자의 대문자와 소문자를 변환합니다.