“^ [[O” e “^ [[I” aparecem no iTerm2 quando o foco é perdido

Estou usando o iTerm2 2.1.1 no Yosemite. No tmux.

Quando o iTerm perde o foco (quando alternado para outro aplicativo com o Cmd-Tab ou clicando em outra janela), a ^[[Ie ^[[Oparece ser enviado ao terminal. Isso faz ^[[I^[[Ocom que apareça, ou seja mais frustrante, no Vim, essa combinação abre outro pequeno buffer.

Amostra: Pressionar Cmd-Tab várias vezes após iniciar cat

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

Isso acontece apenas no iTerm e não no Terminal.app. Além disso, ele é reproduzido no bash ou sh, por isso não parece ser um problema do zsh. Alguns pesquisadores do Google sugeriram que esse é um problema de "foco", mas o que é "foco" no significado de um terminal e existe alguma maneira de desativar ou evitar isso?

De acordo com isso :

Adicione suporte para relatar o foco perdido / ganho. esc [? 1004h liga; então o terminal envia esc [I quando focaliza, esc [O quando desencaixa. Envie esc [? 1004l para desativar.

Cmd- Rredefinir desativará os relatórios de foco (graças a isso )

Não tenho um Mac à mão para testar esta resposta, mas encontro esse problema no XTerm no Linux muito ocasionalmente e (supondo que o iTerm2 respeite os mesmos códigos de controle), você pode achar a correção abaixo útil.

Execute o seguinte comando shell dentro do terminal em que você está vendo o problema:

printf "\e[?1004l"

(Observe que o último caractere existe em minúsculas 'ell'.)

Essa sequência de controle ANSI é semelhante à listada na resposta de Thomas Dickey, mas desativa o recurso (em vez de o ativar). Ele deve resolver seu problema em todos os aplicativos, não apenas no Vim, impedindo a ocorrência dos caracteres.

No Linux, posso demonstrar essa sequência de controle trabalhando com as seguintes etapas:

• Execute xterme ative o recurso executando printf "\e[?1004h"nele.
• Execute xeyesou algum outro aplicativo GUI desse mesmo XTerm . (Por alguma razão, esse efeito não ocorre para mim até que o XTerm em questão inicie um aplicativo. Alguém sabe por quê?)
• Alterne repetidamente o foco para dentro e para fora do XTerm original (por exemplo, clicando nas janelas) e veja ^[[Oe ^[[Isendo "digitado" no XTerm original.
• Agora feche o Xeyes, retorne ao XTerm original e execute printf "\e[?1004l"(para desativar o recurso, conforme descrito na correção acima).
• Repita as etapas " executar xeyes, mudar o foco " acima, mas desta vez não há caracteres sendo inseridos no terminal.

Pessoalmente, só vejo esse problema se despejar inadvertidamente a saída binária no terminal, mas se você a encontrar com mais regularidade, poderá adicioná-la printfao script de inicialização interativa do seu shell (por exemplo ~/.bashrc). Parece não haver nenhum dano (pelo menos no XTerm) ao enviar o código de controle se o recurso já estiver desativado, portanto, deve ser seguro mesmo que você veja esse problema apenas algumas vezes.

Se você está preocupado com o seu shell sempre gerar essa saída, talvez porque você às vezes o use em locais que não lidam bem com esses códigos de controle ou se o problema for desencadeado algumas vezes após a inicialização do shell, você pode preferir definir alias focusfix='printf "\e[?1004l"'crie um alias (por exemplo, com ) para tornar mais conveniente a execução manual.

O termo "foco" refere-se a qual terminal (ou janela) está atualmente aceitando eventos de entrada de teclado e mouse. Somente um pode ter foco; existem protocolos para estabelecer como obter e perder o foco em um ambiente gráfico que não seria útil explorar.

A partir da descrição (consulte também o indicador do painel atual do Tmux quando o foco for recuperado ), parece que o iTerm2 implementa esse xtermrecurso:

FocusIn / FocusOut

O FocusIn / FocusOut pode ser combinado com qualquer um dos eventos do mouse, pois ele usa um protocolo diferente. Quando definido, o xterm envia CSI I quando o terminal obtém o foco e CSI O quando perde o foco.

É ativado pelo modo privado 1004 (adicionado ao xterm em 2007, patch 224 ):

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

e pode estar relacionado a este patch: Vim - Adicionar suporte para o modo de relatório de foco (DECSET / DECRST 1004) funciona em terminais compatíveis com xterm , que igualam todo o comportamento dos recursos do mouse "xterm" em uma configuração:

/ * o relatório de foco é suportado pelos terminais compatíveis com xterm e tmux. * /

Então ... você pode desativar isso dizendo ao vim que seu terminal não usa o protocolo do mouse xterm. O patch citado diz ao vim para ativar o recurso FocusIn / FocusOut (que normalmente deve estar desativado) e, se houver alguma falha em sua lógica, pode deixar o recurso ativado após sair do vim.

Embora o vim seja a causa mais provável do modo estar ativado, é possível que outro programa (ou script) o ligue. Como sugerido em outra resposta, você pode restringir isso coletando a saída para o seu terminal usando o scriptprograma (produzindo um typescriptarquivo). A análise pode levar muito tempo (e como esse site não parece suportar anexos , não parece adequado para solicitar uma discussão detalhada). Eu geralmente uso unmappara transformar arquivos datilografados em forma legível para esse fim.

Para resolver esse problema, você precisa saber qual programa habilita o modo de relatório de foco. Você deve fazer um log gravado pelo comando script (1) .

Encontrei essa pergunta tentando resolver meu terminal exibindo "^ @" quando o foco foi perdido.

Lendo as respostas, tentei acessar as preferências do iTerm2 -> Perfis -> "Padrão" -> Sessão e desmarcar: "Quando estiver ocioso, envie o código ASCII 0 a cada 60 segundos"

Problema resolvido, espero que ajude alguém