Corrigindo CTRL- * no vim na tela GNU

Ao executar o vim na tela GNU, estou descobrindo que combinações de CTRLcom as setas e as teclas Pg * não funcionam como esperado.

Estou usando o vim-gnomepacote Ubuntu 10.10 .

Em uma máquina diferente, também executando o Ubuntu, isso funcionou sem problemas; infelizmente não tenho essa configuração disponível para mim agora.

Há uma pergunta relacionada aqui: Como corrigir setas Ctrl + no Vim?

No entanto, a solução sugerida é remapear as combinações de teclas do vim para trabalhar com o emulador de terminal, nesse caso o PuTTY. Não me lembro de fazer nada desse tipo e suspeito que exista uma opção de configuração de tela que resolva esse problema.

Há também um tópico na lista de discussão do gnu-screen que sugere que a execução do vim via $ TERM=xterm vimé uma correção ou solução alternativa apropriada. Isso funciona, mas estou um pouco preocupado que possa haver efeitos colaterais. Também não parece familiar o suficiente para ser a solução que eu configurei na outra máquina (se for necessária uma solução).

Conforme indicado na atualização, adicionar term xtermao ~/.screenrcarquivo parece corrigir esse problema.

Existem algumas outras maneiras de configurar o terminal que funcionam nos processos em execução:

• Em uma instância de tela em execução, pressionar ^A- :e emitir o comando term xtermfará com que as telas recém-abertas nessa instância iniciem com a $TERMvariável de ambiente definida como xterm; isso, por sua vez, será propagado para viminstâncias invocadas . Essas instâncias do vim exibirão um comportamento adequado em relação aos combos CTRL; Ainda não descobri nenhum efeito colateral dessa estratégia. Este comando não afeta as telas existentes. É claro que este comando pode ser usado em um ~/.screenrcarquivo, portanto, é possível que esse método tenha sido usado na outra máquina.

• Em uma instância do vim em execução, o comando set term=xtermfará com que os CTRL-combos funcionem nessa instância do vim. Isso tem o efeito colateral de desconectar a área de transferência do X (ie @*e @+) por razões que ainda não entendi. Curiosamente, o efeito colateral da área de transferência também acontece quando o comando :set term=screené executado em uma instância do vim iniciada $TERM=xterm.

O problema subjacente é que o mapeamento realizado screenentre o terminal real (identificado pela TERMvariável de ambiente externa screen) e a emulação interna screené incompleto.

Se você testá-lo (usando vttest ou tack ), poderá notar deficiências no

• cores
• chaves especiais

A tentativa de corrigir esses problemas através da criação termem .screenrctem o inconveniente de que ele funciona apenas para um dado real-terminal, e não é portável para outras implementações do terminal. As notas da documentação

O uso do termo command é desencorajado para fins não padrão.

Há outra solução (com uma desvantagem diferente), usando esse recurso da screen documentação :

Quando a tela tenta descobrir um nome de terminal para si mesma, primeiro procura uma entrada chamada tela. term , onde term é o conteúdo da sua $TERMvariável. Se essa entrada não existir, a tela tentará screen(ou screen-w, se o terminal for largo (132 cols ou mais)). Se mesmo essa entrada não puder ser encontrada, vt100será usada como um substituto.

O ncurses fornece várias descrições alternativas úteis de terminais para este caso, por exemplo, screen.xterm-new , para reparar problemas no mapeamento da tela. Na prática, eu uso TERM=xterm-newe, ao executar a tela, obtenho um mapeamento utilizável das teclas de função.

Voltando à termconfiguração da tela , ao testar, você pode perceber que ainda existem problemas com o mapeamento, abordados nessas alternativas. Se fosse possível obter uma descrição precisa do terminal term, essas alternativas seriam aliases simples para screen. Eles não são.

ncurses não fornece screen.xterm(sic) porque:

• TERM=xtermé amplamente utilizado incorretamente em emuladores de terminal que diferem do xterm; adicionar esse mapeamento apenas agravaria essa situação (consulte, por exemplo, Por que não usar TERM definido como "xterm"? nas Perguntas frequentes sobre ncurses)
• screen.xtermé menos provável que o nome alternativo seja instalado em sistemas remotos (consulte o comentário sobre alterações de junho de 2015 no banco de dados do terminal).

No geral, no entanto, o uso de nomes alternativos é uma melhoria em relação ao uso termno seu .screenrc: ele resolve mais problemas do que cria. O inverso é verdadeiro da termconfiguração.