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

18

Estou usando o iTerm2 2.1.1 no Yosemite. Não tmux.

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

Exemplo: Pressionando o Cmd-Tab várias vezes depois de iniciar o cat

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

Isso só acontece no iTerm e não no Terminal.app. Além disso, reproduz no bash ou sh, então não parece ser um problema de zsh. Alguns pesquisando sugeriram que essa é uma questão de “foco”, mas o que é “foco” nos significados de um terminal, e existe alguma maneira de desativar ou evitar isso?

    
por osyoyu 24.06.2015 / 09:05

5 respostas

16

De acordo com este :

Add support for reporting focus lost/gained. esc[?1004h turns it on; then the terminal sends esc[I when focusing, esc[O when de-focusing. Send esc[?1004l to disable.

Cmd - R para redefinir desativará o relatório de foco (Obrigado a this )

    
por 25.12.2015 / 06:13
9

Eu não tenho um Mac à mão para testar essa resposta, mas de vez em quando encontro esse problema no XTerm no Linux e (supondo que o iTerm2 respeita os mesmos códigos de controle) você pode achar a correção abaixo útil.

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

printf "\e[?1004l"

(Observe que o último caractere tem um 'ell' minúsculo.)

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

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

  • Execute xterm e ative o recurso executando printf "\e[?1004h" .
  • Execute xeyes ou algum outro aplicativo GUI desse mesmo XTerm . (Por algum motivo, esse efeito não acontece para mim até que o XTerm em questão inicie um aplicativo. Alguém sabe por quê?)
  • Repetidamente mude o foco para dentro e para fora do XTerm original (por exemplo, clicando no Windows) e veja ^[[O e ^[[I sendo "digitado" no XTerm original.
  • Agora feche 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 , alternar o foco " acima, mas desta vez não há caracteres sendo digitados no terminal.

Pessoalmente, só vejo esse problema se inadvertidamente descartei a saída binária no terminal, mas se você a encontrar com mais frequência, talvez queira adicionar esse printf ao script de inicialização interativo do seu shell (por exemplo, ~/.bashrc ). Não parece haver nenhum dano (pelo menos no XTerm) em enviar o código de controle se o recurso já estiver desabilitado, por isso deve ser seguro mesmo que você veja esse problema apenas às vezes.

Se você está preocupado com o seu shell sempre gerando essa saída, talvez porque às vezes você o use em locais que não lidam bem com esses códigos de controle, ou se o problema às vezes é acionado depois que o shell é inicializado, então você pode prefira configurar um alias (por exemplo, com alias focusfix='printf "\e[?1004l"' ) para facilitar a execução manual.

    
por 28.09.2015 / 17:56
2

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

A partir da descrição (consulte também Indicador de painel atual do Tmux quando o foco recuperado ), parece que o iTerm2 implementa esse recurso xterm :

FocusIn/FocusOut

FocusIn/FocusOut can be combined with any of the mouse events since it uses a different protocol. When set, it causes xterm to send CSI I when the terminal gains focus, and CSI O when it loses focus.

É 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 modo de relatório de foco (DECSET / DECRST 1004) funciona em terminais compatíveis com xterm , o que equaciona todo o comportamento de recursos de mouse "xterm" em uma configuração:

/* focus reporting is supported by xterm compatible terminals and tmux. */

Então ... você poderia desativar isso dizendo ao vim que seu terminal não usa o protocolo do mouse xterm. O patch citado informa 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.

Enquanto o vim é a causa mais provável do modo ser ativado, é possível que algum outro programa (ou script) o ative. Como sugerido em outra resposta, você pode restringir isso coletando a saída para seu terminal usando o script programa (produzindo um arquivo typescript ). Analisando isso pode ser demorado (e como este site não parece suportar anexos , não parece adequado solicitar discussão detalhada). Eu geralmente uso unmap para transformar os arquivos typescript em formato legível para este propósito.

    
por 24.06.2015 / 10:31
0

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

    
por 24.06.2015 / 17:05
-2

Eu encontrei esta pergunta tentando resolver o meu terminal exibindo "^ @" quando o foco foi perdido.

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

Problema resolvido, espero que ajude alguém

    
por 30.09.2016 / 02:34