Como distinguir Ci de TAB?

Normalmente, por razões históricas, o emacs trata o TABcódigo e a C-ichave da mesma forma, cf. a documentação do emacs lisp sobre as teclas de função ou a resposta da abo-abo na pergunta "Qual é a diferença entre TAB e?" .

NOTA: Neste post, keycodes estão TAB, <tab>e C-i; tabe Ctrl+, ipor outro lado, são as teclas físicas do teclado.

No entanto, no momento, o Emacs trata do TABe C-icomo a mesma coisa, ou seja, (equal (kbd "TAB") (kbd "C-i"))-> t.

No entanto, como não estamos mais vivendo na pedra da computação, acho isso extremamente irritante. Existem algumas sugestões por aí, o que pode ser feito para contornar isso, por exemplo

• "Como vincular um comando ao Ci sem alterar o TAB?"

  • A solução da Trey não funcionou para o meu, a variável local-function-key-mapsnão foi alterada. Modificá-lo para usar em deletevez de delqresultar em uma variável modificada, mas não traz a resolução ... tabe Ctrl+ iainda são os mesmos.
  • Traduzir para o hipermap parece uma solução alternativa da década de 1980 ... Talvez eu queira usar Hyper+ itambém.

• Usar o input-decode-mapmapear Ctrl+ ipara algum código de controle pós-ASCII é quase o que estou procurando. Exceto que ele não funciona corretamente com a kbdmacro, o que significa que é preciso modificar todos os bits do código-fonte que vincularão Ctrl+ i. Indiscutivelmente, essa é a melhor solução, pois todo o código-fonte é modificado corretamente.

• Usando (kbd "<tab>")para tabe (kbd "C-i")(que se traduz em (kbd "TAB")ou seja, a \tliteral) para Ctrl+ i funciona , mas você teria que modificar todos os arquivos de origem que usam o tipo errado de tab[Leia-se: o código de acesso TAB] que é irritante.
  Isso foi sugerido, por exemplo, em um problema do github e no emacs.sx também .

Nenhuma dessas soluções parece soluções reais; prefiro considerá-las soluções alternativas ou hacks (do bug existente ).

Existe uma maneira de forçar o emacs a mapear tabpara (kbd "<tab>")e (kbd "TAB")enquanto Ctrl+ ié mapeado para (kbd "C-i")não modificar o código-fonte do emacs?

Essa abordagem deve ser completamente invisível para o usuário, o que significa que os tabcódigos <tab>- chave semelhantes e TABdevem ser mapeados para uma ligação, enquanto o código-chave semelhante Ctrl+ deve mapear para outra ligação.iC-i

Em uma observação menos séria: Algum desenvolvedor do emacs aqui pode comentar se isso será alterado / corrigido no código-fonte do emacs em algum momento?

O futuro já se foi e a idade da pedra da computação está prestes a chegar. Todos os terminais de texto que conheço ainda enviam exatamente a mesma sequência de bytes para o Emacs C-ie TAB, portanto, a necessidade original de "unificá-los" ainda está muito conosco.

O mapa de decodificação de entrada (à la (define-key input-decode-map "\C-i" [C-i])) é provavelmente o melhor possível agora.

Como ex-mantenedor do Emacs, gostaria de ter uma solução melhor para esse problema, a fim de liberar as chaves C-i( C-me C-[) nas GUIs (provavelmente as tornará "reservadas para o usuário"). Mas não sei como fazer isso sem causar muitos problemas nos pacotes existentes.