“^ [[O” dan “^ [[I” muncul di iTerm2 ketika fokus hilang

Saya menggunakan iTerm2 2.1.1 di Yosemite. Tidak ada tmux.

Ketika iTerm kehilangan fokus (ketika beralih ke aplikasi lain oleh Cmd-Tab atau mengklik jendela lain), a ^[[Idan ^[[Otampaknya dikirim ke terminal. Ini menyebabkan a ^[[I^[[Omuncul, atau lebih membuat frustrasi, di Vim, kombinasi ini membuka buffer kecil lainnya.

Contoh: Menekan Cmd-Tab beberapa kali setelah memulai cat

% cat
^[[I^[[O^[[I^[[O^[[I^[[O^[[I^[[O^[[I^[[O^[[I^[[O^[[I^[[O^[[I^[[O^[[I

Ini hanya terjadi pada iTerm dan bukan pada Terminal.app. Juga, itu mereproduksi pada bash atau sh, jadi sepertinya bukan masalah zsh. Beberapa Googling menyarankan bahwa ini adalah masalah "fokus", tetapi apa "fokus" dalam arti terminal, dan apakah ada cara untuk menonaktifkan atau menghindari ini?

Menurut ini :

Tambahkan dukungan untuk melaporkan fokus yang hilang / didapat. esc [? 1004j menyalakannya; kemudian terminal mengirim esc [I saat fokus, esc [O saat de-focus. Kirim esc [? 1004l untuk menonaktifkan.

Cmd- Runtuk mengatur ulang akan menonaktifkan pelaporan fokus (Terima kasih untuk ini )

Saya tidak punya Mac yang berguna untuk menguji jawaban ini, tapi saya mengalami masalah ini di XTerm di Linux sangat sering dan (dengan asumsi iTerm2 menghormati kode kontrol yang sama) Anda mungkin menemukan perbaikan di bawah ini membantu.

Jalankan perintah shell berikut di dalam terminal tempat Anda melihat masalahnya:

printf "\e[?1004l"

(Perhatikan bahwa karakter terakhir ada 'ell' huruf kecil.)

Urutan kontrol ANSI ini seperti yang tercantum dalam jawaban Thomas Dickey, tetapi mematikan fitur (bukan pada). Ini harus menyelesaikan masalah Anda di semua aplikasi, bukan hanya Vim, dengan menghentikan karakter agar tidak terjadi sama sekali.

Di Linux saya dapat menunjukkan urutan kontrol ini bekerja dengan langkah-langkah berikut:

• Jalankan xtermdan aktifkan fitur dengan menjalankannya printf "\e[?1004h".
• Jalankan xeyesatau aplikasi GUI lain dari XTerm yang sama . (Untuk beberapa alasan, efek ini tidak terjadi pada saya sampai XTerm yang bersangkutan meluncurkan aplikasi. Ada yang tahu kenapa?)
• Berganti fokus berulang kali ke dan dari XTerm asli (mis. Dengan mengklik pada windows) dan melihat ^[[Odan ^[[I"diketik" ke dalam XTerm asli.
• Sekarang tutup Xeyes, kembali ke XTerm asli, dan jalankan printf "\e[?1004l"(untuk menonaktifkan fitur, seperti dijelaskan dalam perbaikan di atas).
• Ulangi langkah " jalankan xeyes, alihkan fokus " di atas, tetapi kali ini tidak ada karakter yang dimasukkan di terminal.

Saya pribadi hanya melihat masalah ini jika saya secara tidak sengaja membuang output biner ke terminal, tetapi jika Anda menjumpainya lebih teratur, Anda mungkin ingin menambahkannya printfke skrip startup interaktif shell Anda (misalnya ~/.bashrc). Tampaknya tidak ada ruginya (di bawah XTerm setidaknya) untuk mengirim kode kontrol jika fitur sudah dinonaktifkan, jadi harus aman bahkan jika Anda hanya melihat masalah ini kadang-kadang.

Jika Anda khawatir tentang shell Anda selalu menghasilkan output itu, mungkin karena Anda kadang-kadang menggunakannya di tempat-tempat yang tidak menangani kode kontrol dengan baik, atau jika masalah kadang-kadang dipicu setelah shell dimulai, maka Anda mungkin lebih suka untuk mengatur sebuah alias (misalnya dengan alias focusfix='printf "\e[?1004l"') untuk membuatnya lebih nyaman untuk dijalankan secara manual.

Istilah "fokus" mengacu pada yang terminal (atau jendela) saat ini menerima keyboard dan mouse input peristiwa. Hanya satu yang dapat memiliki fokus; ada protokol untuk menetapkan cara mendapatkan dan kehilangan fokus dalam lingkungan grafis yang tidak akan membantu untuk dijelajahi.

Dari deskripsi (lihat juga Tmux current pane indicator ketika fokus kembali ), tampaknya iTerm2 mengimplementasikan xtermfitur ini :

FocusIn / FocusOut

FocusIn / FocusOut dapat dikombinasikan dengan salah satu peristiwa mouse karena menggunakan protokol yang berbeda. Ketika diatur, itu menyebabkan xterm untuk mengirim CSI I ketika terminal mendapatkan fokus, dan CSI O ketika kehilangan fokus.

Ini diaktifkan oleh mode pribadi 1004 (ditambahkan ke xterm pada 2007, tambalan # 224 ):

CSI ? Pm h
      DEC Private Mode Set (DECSET).
           Ps = 1 0 0 4  -> Send FocusIn/FocusOut events. 

dan mungkin terkait dengan tambalan ini: Vim - Tambahkan dukungan untuk mode pelaporan fokus (DECSET / DECRST 1004) bekerja pada terminal yang kompatibel xterm , yang menyamakan semua perilaku fitur mouse "xterm" dalam satu pengaturan:

/ * Pelaporan fokus didukung oleh terminal dan tmux yang kompatibel xterm. * /

Jadi ... Anda bisa menonaktifkan bahwa dengan mengatakan vim bahwa terminal Anda tidak menggunakan protokol xterm tikus. Patch yang dikutip memberitahu vim untuk mengaktifkan fitur FocusIn / FocusOut (yang biasanya harus dimatikan), dan jika ada beberapa kekurangan dalam logikanya, dapat membiarkan fitur tersebut diaktifkan setelah keluar dari vim.

Meskipun vim adalah penyebab paling mungkin dari mode yang diaktifkan, ada kemungkinan beberapa program lain (atau skrip) menyalakannya. Seperti yang disarankan dalam jawaban lain, Anda dapat mempersempitnya dengan mengumpulkan output ke terminal Anda menggunakan scriptprogram (menghasilkan typescriptfile). Menganalisis yang dapat memakan waktu (dan karena situs ini tampaknya tidak mendukung lampiran , tampaknya tidak cocok untuk meminta diskusi terperinci). Saya biasanya menggunakan unmapuntuk mengubah file naskah menjadi bentuk yang dapat dibaca untuk tujuan ini.

Untuk mengatasi masalah ini, Anda harus tahu program apa yang memungkinkan mode pelaporan fokus. Anda harus mengambil log yang direkam dengan perintah skrip (1) .

Saya menemukan pertanyaan ini dengan mencoba menyelesaikan terminal saya menampilkan "^ @" ketika fokus hilang.

Membaca jawaban, saya mencoba masuk ke preferensi iTerm2 -> Profil -> "Default" -> Sesi dan hapus centang: "Saat idle, kirim kode ASCII 0 setiap 60 detik"

Masalah terpecahkan, semoga membantu seseorang