Atualização: a mesma coisa acontece com todos os dígitos quando combinados com Alt Gr .

Você sabe, isso provavelmente é por minha conta. Provavelmente não estamos obtendo vkey corretamente para combos AltGR em algum lugar em TermControl.cpp, quando obtemos o evento KeyDown.

Meio não relacionado, mas qual software você usou para obter uma gravação com as teclas que pressionou no gif @patriksvensson ?

@watermelonpizza Eu usei Carnac para exibir as teclas pressionadas e ScreenToGif para capturar a janela.

Oh carnac, muito obrigado! Vou adicionar isso à minha lista de guloseimas :)

Acho que esta é uma duplicata de # 487.

Opa, parece que a mão esquerda não sabe o que a mão direita está fazendo, e acabei de criar um link duplicado circular.

Pode confirmar este problema no Windows versão 10.0.18362.30 com layout de teclado húngaro. O comportamento é diferente, dependendo de qual console estou usando:

• cmd: ele apenas escreve o caractere, mas em maiúsculas
• PowerShell: não faz nada
• git bash: não escreve nada, mas toca o bipe padrão

@ zadjii-msft Eu encontrei seu comentário relacionado ao (?) AltGr em terminalInput.cpp .
No meu teclado alemão, o estado da tecla de controle é LEFT_CTRL_PRESSED | LEFT_ALT_PRESSED vez do aparentemente esperado LEFT_CTRL_PRESSED | RIGHT_ALT_PRESSED .
Além disso, a tecla virtual pressionada é, por exemplo, "Q" em vez de alguns caracteres Unicode já transformados.

Assim eu substituí ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
com...

if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed())
{
    return false;
}

... e funciona! Por enquanto. 😅 Ele vai delegar o manuseio a WM_CHAR / _CharacterHandler que segundo o Google é mais robusto para o manuseio de AltGr. (?) (Não estou muito familiarizado com a programação do Windows ainda.)
O que você acha disso? Devo enviar um PR?

@lhecker Awesome! Agora, isso é realmente utilizável 🎉

@lhecker Sim, envie um PR. Em teclados alemães, não consigo inserir o pipe agora, o que torna o terminal meio difícil de usar.

Eu sinto que minha mudança está incorreta. Deve haver um motivo pelo qual nem todos os personagens são controlados por WM_CHAR certo?
Devido a isso, gostaria de esperar pelo feedback de @zadjii-msft ou @ DHowett-MSFT primeiro. Eu acho que? 😅

A causa real está em Terminal.cpp

DWORD modifiers = 0
                      | (ctrlPressed? LEFT_CTRL_PRESSED : 0)
                      | (altPressed? LEFT_ALT_PRESSED : 0)
                      | (shiftPressed? SHIFT_PRESSED : 0);

Você pode ver que RIGHT_ALT_PRESSED nunca é detectado corretamente aqui, o que faz com que keyEvent.IsAltGrPressed em TerminalInput :: HandleKey retorne falso.

A propósito, o estado dos modificadores é adquirido por _GetPressedModifierKeys () em TermControl :: _ KeyDownHandler (). em vez de um valor booleano, você pode passar o estado dos modificadores diretamente para SendKeyEvent e determinar se o ctrl esquerdo / direito, alt esquerdo / direito, shift esquerdo / direito é pressionado mais tarde.

E já estão definidos como segue no VirtualKey, que pode ser usado em TermControl :: _ GetPressedModifierKeys ()

        LeftShift = 160,
        RightShift = 161,
        LeftControl = 162,
        RightControl = 163,
        LeftMenu = 164,
        RightMenu = 165,

Ah, boa captura @sagood!
Infelizmente, corrigir esse problema não será suficiente, pelo que posso ver ...
TerminalInput::HandleKey aparentemente assume que quando AltGr é pressionado, o sistema operacional já "pré-traduziu o UnicodeChar para o valor alternativo adequado", o que não é o caso, por exemplo, de AltGr + Q (= @) em um teclado alemão.
Significando que a lógica atual em torno de IsAltGrPressed() já está meio falhada.

@lhecker Tentei usar RIGHT_ALT_PRESSED em vez de inicializar os modificadores DWORD. Testei AltGr + '+' (= ~), será mostrado corretamente no console.
AltGr + <(= |) também funciona.

Mas AltGr + Q não parece funcionar de fato. esquisito.
AltGr + E (= €) também não funciona.

Ao configurar um novo c # UWP, observei que a sequência de teclas ao usar AltGr é a seguinte,

Menu
Control
Q

(tome AltGr + Q como exemplo)

Uma depuração posterior mostra que se você forçar o programa a executar o primeiro branch de condição de TerminalInput :: HandleKey de terminalInput.cpp conforme mostrado abaixo,

if (!fKeyHandled)
            {               
                if ((keyEvent.GetVirtualKeyCode() < '0' || keyEvent.GetVirtualKeyCode() > 'Z') &&
                    keyEvent.GetVirtualKeyCode() != VK_CANCEL)
                {
                     // !!!force the AltGr+'Q/E' case to run here, not the one below
                    fKeyHandled = _TranslateDefaultMapping(keyEvent, GetKeyMapping(keyEvent), GetKeyMappingLength(keyEvent));  
                }
                else
                {
                    ...
                }
            }

AltGr + Q funcionará.

Que tal AltGr + ß para \ no teclado alemão, esse tem o mesmo problema

Todas as combinações de teclado AltGr são afetadas pelo mesmo problema.

Algum progresso nisso? Consegui replicar o comportamento, mas não tenho certeza de como o caso AltGr deve realmente ser tratado. Caso ajude, aqui estão algumas coisas que observei:

• Verifiquei que, em um teclado alemão, AltGr é de fato traduzido para Left_CTRL && LEFT_ALT , testado para CMD, PS e WSL
• Parece que o bug está relacionado a testes que não passaram. Os seguintes testes falham para mim ao mudar para um teclado alemão, mas passam no teclado inglês:
  
  
  
  • InputEngingeTest:C0
  
  
  • InputTest::TerminalInputModifierKeyTests#metadataSet3 até e incluindo set10
  
  

@lhecker Por curiosidade, apliquei sua primeira ideia de substituir isAltGrPressed() por isAltPressed() && isCtrlPressed() e verifiquei que:

• funciona para CMD incluindo @ e €, mas não em PS ou WSL
• realmente não corrige os testes de não aprovação
• mas em vez disso quebra MouseInputTest::SgrModeTests#metadataSet20 para o teclado inglês.

Mesmo que eu não tenha ido muito longe em estreitar ainda mais o problema, pensei que as informações poderiam ser úteis.

Isso é muito interessante, @MattKuhr. @ e € realmente funcionam para mim no PowerShell e no WSL. 🤔
(Só para ter 100% de certeza - esta é a minha diferença no master 67f68eb atual.)

É verdade, eu atualizei para o mestre atual e testei novamente. Agora os caracteres especiais funcionam, exceto € em PS.

Não tenho certeza do que causou o comportamento que observei antes, exatamente as mesmas alterações de código foram usadas. Estou começando a pensar que posso ter bagunçado algo com a implantação durante o teste, embora tenha testado várias vezes, ou algumas atualizações do Windows que foram instaladas nesse meio tempo tiveram um efeito.

Esta é uma captura de tela com o teclado alemão definido durante o teste no mestre atual:

Eu testei em Debug e Release (x64), Win 10.0.18362.116. Também tentei alterar o idioma do sistema, mas não surtiu efeito. Parece um pouco estranho que apenas neste caso específico o € não seja traduzido corretamente.

Digamos, ele começa a funcionar no PowerShell se você primeiro Remove-Module PSReadline ? (Não se preocupe: isso afetará apenas sua sessão atual.) Nesse caso, temos algumas ideias!

@ DHowett-MSFT Eu testei com uma versão do checkout principal de ontem, sem alterações em um layout de teclado alemão em 18362.113 (a configuração de idioma é inglês)

Alt Gr + q => Q , esperado @
Alt Gr + < => < , esperado |
Alt Gr + + => + , esperado ~
Alt Gr + ß => ß , esperado \
Alt Gr + 2 => 2 , esperado ²
Alt Gr + 3 => 3 , esperado ³
Alt Gr + e => E , esperado €

Para caracteres regulares, Alt Gr funciona como shift. Qualquer outro caractere é deixado no valor sem modificador.

@ DHowett-MSFT Na verdade, 😃

As outras chaves continuam funcionando. Além disso, anteriormente o pequeno 3 seria escrito como o 3 normal, agora ele aparece corretamente, como você pode ver na imagem abaixo.

Oi,

Só aqui para dizer que isso também afeta o layout QWERTY finlandês, tornando todas as combinações AltGr como @, |, {}, [], ~, \ etc. inutilizáveis.

Todos esses parecem funcionar bem com o patch de @lhecker no WSL, cmd e powershell. Obrigado @lhecker !

Olá, também funciona com o layout de teclado francês Azerty. Obrigado @lhecker

Problemas com combinações Alt Gr, por exemplo, “Alt Gr + <” (Barra invertida, mas resulta em “<”) em um teclado alemão suíço.

Atualizei o título desta edição para tornar mais óbvio para os transeuntes o que ele está rastreando.

@ zadjii-msft Eu encontrei seu (?) comentário relacionado ao AltGr em terminalInput.cpp.
Assim eu substituí ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
com...
if (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
retorna falso;
}
... e funciona! Por enquanto. 😅

Essa mudança também me dá um AltGr utilizável no meu teclado francês. Testado até agora com CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (ambos com o PSReadline 2.0.0beta4 não oficial que é necessário para trabalhar no VScode)

Essa mudança também me dá um AltGr utilizável no meu teclado francês. Testado até agora com CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (ambos com o PSReadline 2.0.0beta4 não oficial que é necessário para trabalhar no VScode)

Verifiquei minha versão do PSReadline e atualizei de 2.0.0 para 2.0.0-beta4 e funcionou, agora € e ³ também estão funcionando corretamente no PS, 5.1 e 6.2.1. 😄

Embora eu tenha encontrado outro bug que também parece estar relacionado ao PSReadline, mas não ao AltGr ou ao layout do teclado diretamente. Como você pode ver abaixo, no Terminal CTRL 2 é traduzido para " e CTRL 7 (no layout GER, nos EUA é CTRL / ) para ^_

Para o primeiro caso, Remover PSReadline resolve, para o segundo, não. Tentei o outro número e as chaves especiais de char, mas esses dois foram os únicos dois exemplos que consegui encontrar até agora. O comportamento é idêntico para 5.1 e 6.2.1. PSReadline é 2.0.0beta4.

Devemos abrir uma edição separada para isso?

Também vejo problemas relacionados em um teclado de português (Portugal).
Esperado: Alt Gr + 2/3/4/7/8/9/0 deve produzir @ £ § {[]}, Alt Gr + e deve obter €

Terminal Windows:
-PS Core: Alt Gr + dígitos dispara PSReadline DigitFunction, exceto 7 saídas ^ _
-PS Core: Alt Gr + € não faz nada
-Windows Powershell: Igual ao PS Core
-CMD: Alt Gr + dig produz o dígito, exceto 7 saídas ^ _
-CMD: Alt Gr + e saídas E

Console integrado:
PS Core: Alt Gr + 2/3/4/7/8/9/0 output @ £ § {[]}, Alt Gr + E não faz nada
Windows PowerShell: igual ao PS Core
CMD - Todas as obras

Windows 10 1903 18362.116
PS Core 6.2
Terminal Windows 0.1.1431.0
PSReadline 2.0.0

Uma solução alternativa experimentada e comprovada quando as combinações de teclas "Alt Gr" não funcionam é usar Alt + NumPad Code .

Mas isso também não funciona!

657 "Alt + Numpad não funciona"

Eu aconselharia que quem quer que fale com este também fale com este intimamente relacionado.

Posso verificar isso também para o teclado islandês. Usamos AltGr para escrever estes:
@ | € {[]} \ µ ~ `^

Apenas uma observação: esse problema surge em quase todas as tecnologias de linha de comando da Microsoft. Já surgiu no OpenSSH , um problema semelhante surgiu no PSReadline e aqui novamente, onde nenhuma das combinações AltGr não funciona.

Sempre que tento algo na linha de comando, sempre surgem problemas de entrada. Ainda não consigo usar o PowerShell em sessões remotas, porque o Home-End não funciona e eles ainda não funcionam por meio de SSH.

De alguma forma, este triângulo terminal-SSH-PSReadline está amaldiçoado.

Aqui estou usando o layout de teclado PT-BR.

Para obter / eu uso Alt Gr + Q

Ao usar no Terminal, funciona como um comando de desfazer. Basta digitar novamente meu último comando / letra / palavra

@MathiasMagnus

onde nenhuma das combinações AltGr não funciona.

Você quer dizer que nenhuma das combinações AltGr funciona?

Digamos, ele começa a funcionar no PowerShell se você primeiro Remove-Module PSReadline ? (Não se preocupe: isso afetará apenas sua sessão atual.) Nesse caso, temos algumas ideias!

Não funciona para mim (layout AZERTY em francês)

então ... alguma ideia nova? porque a correção ...

`` `c ++
if (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
retorna falso;
}
...

não funcionou para mim <. <

Editar:

Não é mais inteligente detectar o idioma do teclado principal, que está definido na máquina, e depois fazer o rebind -stuff

@Hedrauta estranho que a mudança de código não funcione para você. Qual layout de teclado você está usando? O que Ctrl+Alt+xxx faz por você em um CMD normal para valores de xxx que são usados ​​em combinação com AltGr? Tanto quanto me lembro, Ctrl+Alt deve ser sempre equivalente a AltGr ...

Então, para coletar alguns dados de teste: Para mim, o patch de @lhecker parece funcionar bem. Este é um layout de teclado alemão:

Terminal | Alt Gr + ß? \ | Strg + Alt + ß? \
- | - | -
Legado cmd.exe | \ | \
Legado pwsh.exe | \ | \
Terminal Windows, master , cmd.exe | ß | ß
Terminal Windows, master , pwsh.exe | _ (nada) _ | _(nada)_
Terminal Windows, master + Patch por @lhecker , cmd.exe | \ | \
Terminal Windows, master + Patch por @lhecker , pwsh.exe | \ | \

mesmo resultado que em https://github.com/microsoft/terminal/issues/521#issuecomment -501148984
com o Patch por @lhecker

Mas em pwsh o sinal de € ainda não está funcionando no layout alemão.

cmd:
C:\Users\jkann>2² 3³ 7{ 8[ 9] 0} ß\ +~ <| Q@ E€
pwsh:
PS C:\Users\jkann> 2² 33 7{ 8[ 9] 0} ß\ +~ <| Q@ E

@Hedrauta estranho que a mudança de código não funcione para você. Qual layout de teclado você está usando? O que Ctrl+Alt+xxx faz por você em um CMD normal para valores de xxx que são usados ​​em combinação com AltGr? Tanto quanto me lembro, Ctrl+Alt deve ser sempre equivalente a AltGr ...

Também não me ajudou ...
Eu até tentei fazer minha própria solução alternativa com base nesse código, mas sem sorte até agora ...

Estou usando o layout de teclado PT-BR, tentando a seguinte combinação:

CMD, Powershell e WSL.exe
AltGr + Q = /

Ao usar o Terminal Windows
WSL: AltGr + Q = funciona como um comando de desfazer, ele reescreve meus últimos caracteres digitados.
Powershell, CMD: AltGr + Q = produz este estranho char imprime como ^_

Editar:
Para ajudar a visualizar:

A entrada correta deve ser
AltGr + Q = /
AltGr + W = ?
AltGr + [ = ª
AltGr + ] = º

@ renatop7 o que você obtém com CtrlAlt em vez de AltGr?

@ renatop7 o que você obtém com CtrlAlt em vez de AltGr?

O mesmo resultado

E fora do Terminal, ou seja, em CMD padrão ou Windows Powershell ou Powershell Core? CtrlAlt sempre se comporta como AltGr?

E fora do Terminal, ou seja, em CMD padrão ou Windows Powershell ou Powershell Core? CtrlAlt sempre se comporta como AltGr?

Sim, fora do Terminal funciona perfeitamente.
Usando com AltGr ou Ctrl + Alt obtenho o resultado esperado.

buscado há 15 minutos: sem trabalho
bem, a microsoft trabalha em uma solução relacionada a esse problema?

@Hedrauta estranho que a mudança de código não funcione para você. Qual layout de teclado você está usando? O que Ctrl+Alt+xxx faz por você em um CMD normal para valores de xxx que são usados ​​em combinação com AltGr? Tanto quanto me lembro, Ctrl+Alt deve ser sempre equivalente a AltGr ...

Uhm, um alemão padrão ?. aqui uma tela de como fica: https://i.imgur.com/mvgHkxi.png
Vou tentar digitar a chave por meio de uma macro ... teste

é tipo, meu alt esquerdo é Shift, não Alt ...
Resultado experimentado
Ctrl + Q ^ Q
CTRL + Alt + QQ
apenas Q q
Alt + QQ

Vou tentar o gif, atualizando o comentário então
Edit: ao tentar dar um gif, percebi que minha Alt-Key é reconhecida incorretamente .... alguém sabe, onde as teclas virtuais são definidas? também examinarei;) mas não tenho muita experiência em c ++ ou .... qualquer codificação;)

Só para mim como noob cpp, verifiquei vários arquivos e encontrei o
C: \ Arquivos de programas (x86) \ Windows Kits \ 10 \ Include \ 10.0.17763.0 \ um \ WinUser.h
Então .... para layouts alemães, o VK_Menu não existe, certo? nós apenas possuímos o VK_LMENU, certo?
Vou tentar algumas mudanças e fazer alguns testes ... vou editar nos resultados mais tarde
Edição 1: a construção está demorando muito, assim como reconstruo todos os meus sistemas oO
Edit 2: depois de construir a coisa toda, não está funcionando ... mas percebi que VK_RMENU é AltGr, enquanto VK_LMENU é a tecla que queremos ver pressionada para obter nosso @ ou \
mas VK_MENU também parece funcionar, mas pode estar atribuído errado
Isso está me confundindo um pouco, vou verificar este depois de uma busca limpa, reconstrução e um cochilo

Para o layout do teclado alemão é ainda pior, porque Alt Gr + Q que deve apenas imprimir @ , exclui a entrada de linha atual.
Isso não acontece com wsl, nem o vejo configurado para WT - então, como isso acontece?

Ainda é um problema:
Teclado: Belga (ponto) AZERTY, funciona em shell normal
Winver: 18362,175
Versão do terminal: 0.2.1715.0

_Eu gostaria de pedir a todos que não comentem que eles também estão lidando com este problema._

Agora deve estar claro para todos que esse problema afeta uma ampla quantidade de combinações de teclas e pode resultar em uma quantidade igualmente ampla de efeitos colaterais inesperados, para uma quantidade igualmente ampla de idiomas, versões do Windows, teclados, etc.
Mais da metade dos comentários é do tipo #metoo, o que não ajuda em nada a corrigir esse problema e
apenas torna os comentários úteis menos visíveis .
O que realmente está faltando e seria de grande ajuda é que um desenvolvedor Windows experiente resolva esse problema e envie um PR.

Nesse ínterim, todos os capazes de compilar este projeto podem se sentir à vontade para substituir este pedaço de código: https://github.com/microsoft/terminal/blob/ce4c6d6124c258c676b4eeac61a709c1fb3da459/src/terminal/input/terminalInput.cpp#L392 -L396

com esta minha correção experimental:

if (keyEvent.IsAltPressed() && keyEvent.IsCtrlPressed())
{
    return false;
}

Isso deve corrigir a maioria das combinações de teclas para a maioria dos idiomas de teclado, incluindo, por exemplo, caracteres como @{}[] em um teclado alemão (ou similar).

PS: Não sou afiliado à Microsoft de nenhuma forma ou forma e estou escrevendo isto porque pessoalmente considero esses comentários "#metoo" como muito barulhentos / improdutivos. 🙂
PPS: Tenho certeza de que alguns estão se perguntando por que eu mesmo não envio um PR. Para citar a mim mesmo : "Eu sinto que minha alteração está incorreta. Deve haver um motivo pelo qual nem todos os caracteres são manipulados por WM_CHAR certo?" O que significa que eu realmente não sei quais são as desvantagens da correção acima e como fazê-lo corretamente.

PPS: Tenho certeza de que alguns estão se perguntando por que eu mesmo não envio um PR. Para citar a mim mesmo: "Eu sinto que minha alteração está incorreta. Deve haver um motivo pelo qual nem todos os caracteres são manipulados por WM_CHAR certo?" O que significa que eu realmente não sei quais são as desvantagens da correção acima e como fazê-lo corretamente.

Uma forma de saber seria enviar um PR e ser corrigido pela equipe. É um pouco exagero, mas acho que faria as coisas andarem mais rápido.

@NatoBoram 😤👉 #1436

Observe que, ao usar os aplicativos de exemplo, por exemplo, VtPipeTerm, a tecla alt-gr funciona lá.

@HBelusca VtPipeTerm não é baseado no novo Terminal UWP e, portanto, não terá esse problema.
Você pode ler # 1436 para uma possível explicação do problema subjacente.

@lhecker não é baseado em Cascadia, mas usa a mesma implementação de pseudoconsole subjacente ... portanto, é extremamente útil saber que não se aplica a todos os consumidores de pseudoconsole!

Obrigado @HBelusca

As teclas especiais funcionam há anos em terminais e aplicativos do Windows. Por que temos esse problema agora em 2019? Você reimplementou completamente o sistema de entrada para o programa do terminal? Espero que tenha sido necessário fazer isso e reintroduzir os bugs que foram corrigidos anos atrás: s. Este problema era típico no Linux devido a páginas de código, mapeamentos de teclado de idioma e teclas específicas do Windows, mas este bug crítico está na versão de visualização do aplicativo, que está disponível na loja e divulgada em todos os lugares

@ifilgud É uma versão prévia disponível na loja por motivos de prévia . Este problema foi triado e também há um PR enviado para ele, então não há necessidade de comentar sobre este problema apenas para reclamar.

@patriksvensson Sei que estava reclamando principalmente e isso não é "educado", mas também perguntei por um motivo técnico para explicar o motivo de um bug como esse. Eu esperava ter alguns pequenos erros para corrigir em uma versão quase finalizada (visualização), mas não um que não deveria ter existido em uma evolução de um terminal, a menos que tenha sido escrito do zero e testado apenas em inglês (acho que esse é o motivo para não detectar isso na primeira versão alfa). Abri o terminal e tentei escrever "cd \" como o segundo comando (o primeiro era "dir") e simplesmente não funcionou. Como desenvolvedor de software, isso me impactou muito.

@lhecker até agora, tudo bem, depois de aplicar sua correção experimental. Muito Obrigado!!

Muito obrigado a todos que apontaram isso e já corrigiram. 🌷

Com que frequência o aplicativo da MS Store será atualizado?
Então, quando podemos esperar ter coisas corrigidas no aplicativo da loja?

Adoraria trabalhar com o terminal, mas com o teclado alemão, você não consegue nem escrever { } sem altgr. 😅

O mesmo problema ocorreu com o layout do teclado Norwegian Bokmål (nb-NO). Não é possível criar [] ou {} ou $. PowerShell está basicamente quebrado sem eles.
Usando UWP / Microsoft Store versão 0.2.1715.0 no Windows 10 1903 18362.175.

Layout hu_HU via AltGr: \ | & @ $ ; # <> {} [] Quero dizer, com que frequência eu abro colchetes, colchetes angulares ou quadrados, barra invertida, barra vertical, cifrão, marca hash, "em", "e", ponto e vírgula ... oh espere, cada linha ?? :)

_Eu gostaria de pedir a todos que não comentem que eles também estão lidando com este problema._

Agora deve estar claro para todos que esse problema afeta uma ampla quantidade de combinações de teclas e pode resultar em uma quantidade igualmente ampla de efeitos colaterais inesperados, para uma quantidade igualmente ampla de idiomas, versões do Windows, teclados, etc.
Mais da metade dos comentários é do tipo #metoo, o que não ajuda em nada a corrigir esse problema e
_apenas torna os comentários úteis menos visíveis_.

Atualização: a mesma coisa acontece com todos os dígitos quando combinados com Alt Gr .

como você fez esse registro gif?

@ Karl-WE Olhe mais adiante no tópico.

@ DHowett-MSFT Pode ser uma boa ideia bloquear este tópico com uma mensagem na parte inferior

Embora o terminal esteja muito inutilizável para Powershell enquanto este problema estiver ativo
Eu gostaria de apresentar uma solução alternativa para o Windows 10 1903 para aqueles que não podem se conter até que sejam corrigidos.

Gambiarra:
use a tecla Windows +.
vá para a guia de personagem especial selecione seu personagem
mude para o Terminal e insira o caractere

Deixá-lo desbloqueado dá às pessoas um espaço para relatar cada chave individual que não funciona, para que parem de preencher _edições_ individuais sobre cada chave individual que não funciona. Estou dividido.

Pode haver mais casos em que os caracteres especiais não se comportam conforme o esperado. Se eu quiser fazer um caractere @ em um teclado dinamarquês, há 3 maneiras de fazer isso: Alt Gr + 2, Ctrl esquerdo + Alt esquerdo + 2 ou Alt esquerdo + teclado numérico 64
As 2 primeiras opções dão o resultado OP relatado.
A última opção faz no PowerShell:
Onpres Alt esquerdo + teclado numérico 64 digit-argument: 64
Onrelease Alt esquerdo: 64 @ caracteres
Em cmd
Onpres Alt esquerdo + teclado numérico 64: 64
Onrelease Alt esquerdo: @ resultando em 64@
Em wsl
Onpres Alt esquerdo + teclado numérico 64: (arg: 64)
Onrelease Alt esquerdo: 64 @ caracteres

Bom ponto @saadanerdetbare!

Seu problema com Alt + Numpad parece resultar do fato de que o novo Terminal (Cascadia) envia códigos de escape apropriados para o shell quando você insere esses códigos. Mas, simultaneamente, outra parte do aplicativo está _também_ tratando desse caso, traduzindo o código Alt + Numpad em um caractere apropriado e inserindo-o no shell. Isso leva ao efeito colateral engraçado de seu caractere @ ser repetido 64 vezes (devido ao envio dos seguintes bytes para o shell: \x1b6\x1b4@ ).

Você pode tentar isso adicionando o seguinte código adicional entre essas duas linhas :

if (!inEventsToWrite.empty() && static_cast<KeyEvent*>(&*inEventsToWrite.front())->GetCharData() == '\x1b')
{
    return;
}

Isso impedirá o Cascadia de enviar esses códigos de escape para o shell. Depois disso, seus personagens (por exemplo, @) aparecerão normalmente.
Alternativamente, você pode remover este bloco de código para o mesmo efeito.

~ @saadanerdetbare Seria muito bom se você pudesse criar uma edição separada detalhando seu problema, já que este é um bug não relacionado à funcionalidade do AltGr. 🙂 ~
👉 # 1401
Deveria ter procurado outras questões primeiro. 🤦‍♂️

PS: Devo dizer, porém, que ver uma maior disposição da comunidade para depurar essas coisas por conta própria, em vez de depender de outros desconhecidos, me deixaria pessoalmente muito orgulhoso. 🙈🙂

@saadanerdetbare adie o preenchimento de uma nova edição, essa é # 1401: smile:

Ainda estou sentindo isso no aplicativo de visualização, tenho um teclado belga, impossível de escrever @

@solispauwels, você terá que esperar até o próximo lançamento (ou construir você mesmo o branch master atual por enquanto).

Olá, acabei de testar este commit em um teclado alemão e tudo funciona além do altgr-E que deve imprimir o símbolo €. Para ser honesto, eu realmente não preciso disso em um terminal com tanta frequência, mas pensei que poderia mencioná-lo de qualquer maneira. Outros, como altgr-m para µ, funcionam.

Atualização: acho que você pode ignorar isso, o símbolo € também não funciona em um PowerShell padrão, então não parece ser a falha do terminal, deveria ter verificado isso antes.

Tudo parece funcionar aqui em um teclado francês: AltGr+é"'(-è_çà)=$e produz o esperado ~#{[|`\^@]}¤€

Estou usando um teclado francês também (mas estou na Bélgica) e estou tendo problemas com o AltGr +personagens. | # {} @ por exemplo, não funcionam. Estou usando a versão mais recente da loja do Windows 0.2.1715.0 no Windows 10 v1903.

@meuter, você terá que esperar até a próxima versão (ou construir você mesmo o branch master atual por enquanto).

A correção de # 1436 ainda não está incluída na versão de visualização disponível na Microsoft Store

@antoineco @ sba923 obrigado, foi o que imaginei. Acabei de clonar o repo. Assim que meu vs2017 terminar com a atualização, vou reconstruí-lo a partir da fonte :-)

Obrigado a todos por trabalhar tão arduamente nisso e preencher nossas caixas de entrada com relatórios. Agradecemos especificamente a @lhecker por enviar uma correção! Acabamos de enviá-lo para a loja com a versão de serviço v0.2.1831.0. Pode levar algum tempo para a loja processá-lo.

Acabamos de enviar para a loja

Portanto, pela minha experiência com a publicação de aplicativos na Windows Store, deve levar de 3 dias a 3 semanas 😉

Acabamos de enviar para a loja

Portanto, pela minha experiência com a publicação de aplicativos na Windows Store, deve levar de 3 dias a 3 semanas 😉

Menos de 6h, ao que parece. 😋

De qualquer forma, no meu teclado sueco tudo parece bem agora. 👍

Funciona com o teclado alemão agora 👍

Funciona com teclado francês na versão 0.2.1831.0! obrigado

Funciona com teclado francês na versão 0.2.1831.0! obrigado

Confirmado!

Bom trabalho!

@ DHowett-MSFT O v0.2.1831.0 parece incluir esta correção, mas não outras correções de bug como fontes powerline ou copiar / colar keybings, isso é normal?

Confirmo que Alt-Gr funciona, mas usar Ctrl-Alt para acessar as mesmas teclas do teclado não funciona de forma confiável (se funcionar).

Na versão 0.2.1831.0, as combinações AltGr agora funcionam com teclado finlandês.

@solispauwels as únicas correções na versão 0.2.1831.0 são as mencionadas nas notas de lançamento.

Saiba que muitos sistemas operacionais 1803 ou posteriores podem enfrentar um bug com a versão da Windows Store 11905.1001.4.0
A loja irá "empilhar" os aplicativos a serem baixados (consulte a imagem), mas não baixará os aplicativos, mesmo com o download automático habilitado e a rede não seja uma conexão medida.

Os usuários afetados devem pressionar "Verificar atualizações" na Microsoft Store para, eventualmente, obter um aplicativo fixo da loja e iniciar todos os downloads de aplicativos pendentes.

Confirmo que este problema foi corrigido com a nova versão do Terminal. Muito Obrigado.

Posso confirmar também que isso foi corrigido agora. Você pode querer desafixar o problema.

Funciona exceto a tecla Euro, que é AltGr + e, pelo menos no teclado espanhol. O resto das combinações funcionam corretamente

De @ifilgud

Funciona exceto a tecla Euro, que é AltGr + e, pelo menos no teclado espanhol. O resto das combinações funcionam corretamente

Testado no Windows 10 1903 (18362.175) usando a versão mais recente em 08/07/2019 usando o teclado AZERTY "belga (período)".

Resultado do teste:

• todas as combinações que tenho disponíveis no meu teclado, incluindo o símbolo da moeda Euro (€), funcionam em 2 dos 3 consoles configurados como padrão no Terminal do Windows: PowerShell Core e 'cmd' (prompt de comando do Windows)
• Apenas no "Windows PowerShell" o símbolo do Euro (€) não funciona
  
  
  
  • No entanto, não trabalho no Console clássico PowerShell lançado diretamente do Windows Iniciar bem
  
  

Imo, este é um novo problema relacionado ao Windows PowerShell, não específico ao Terminal Windows que hospeda esse console.

Confirmo a observação do @DeChrist . Por outro lado, pressionar Ctrl-Alt + (tecla) não funciona como esperado (se alguém quiser usar esta combinação em vez de AltGr).

Aqui no Windows 10 construir 18.362,175 executando o Windows Terminal prévia versão 0.2.1831.0, com um teclado francês, AltGr+E rende € em todos os seguintes conchas:

• cmd
• Windows PowerShell 5.1
• PowerShell Core 6.2.1
• PowerShell Core 7.0.0-preview.1

Qualquer pessoa com AltGr problemas restantes _ no PowerShell_ pode verificar qual versão de PSReadLine está executando?

$psrl = Get-Module PSReadLine $psrl.Version $psrl.PrivateData.PSData['Prerelease']

@ sba923 :

PS C:\Users\myself> $psrl = Get-Module PSReadLine
PS C:\Users\myself> $psrl.Version

Major  Minor  Build  Revision
-----  -----  -----  --------
2      0      0      -1

PS C:\Users\myself> $psrl.PrivateData.PSData['Prerelease']
beta2

@HBelusca, você poderia tentar:

1. desabilitando PSReadLine
2. atualizando para o beta4 mais recente, consulte https://github.com/PowerShell/PSReadLine

• Windows 10 1903
• Terminal Windows 0.2.1831.0
• PowerShell v7 (que inclui PSReadline 2.0.0-beta4)
• Layout de teclado QWERTZ alemão

✅ AltGr + Q → @
✅ AltGr + E → €
❌ Ctrl + Alt + Q → q

Isso é especialmente frustrante, pois há outro bug relacionado a mstsc que a Microsoft tem ignorado por pelo menos uma década, onde AltGr + Q para de funcionar se uma sessão RDP estiver aberta. Nessas situações, Ctrl + Alt + Q ainda funciona, então muitas pessoas o usam como uma solução alternativa.

O que a Microsoft DEVE fazer é NÃO TOCAR NO STREAM DO TECLADO.

O shell (explorer.exe) deve capturar todos os pressionamentos de tecla de que precisa e passar todo o resto a jusante.
Terminal.exe deve, em última análise, APENAS capturar Alt-F4 - e talvez nem isso - explorer.exe realmente deve capturar isso e aplicar ao processo ativo.

O que significa que Terminal.exe deve apenas pegar o fluxo do teclado e passá-lo para o processo filho ativo. Nada mais.

O CMD.exe [command.com] deve saber como capturar o que precisa e, em seguida, passar o restante para seus próprios filhos.

WSL deve obter o máximo de entrada bruta possível. NÃO maltrate o AltGr. Ctrl-Alt e AltGr NÃO são as mesmas sequências de teclado. No Linux, existem atalhos usando ctrl-alt -... que produzem resultados diferentes de AltGr -...

Você tem apenas UMA oportunidade de fazer isso corretamente. A primeira oportunidade em quase 40 anos. Por favor, não perca essa oportunidade - Microsoft, estou olhando para você :)

@thorsig ah, se apenas tivéssemos você por perto quando a pilha de entrada do Win32 foi arquitetada há quarenta e tantos anos. Infelizmente, não o fizemos, então existem duas maneiras principais de receber entrada do teclado:

• como caracteres, sem modificadores (portanto, não podemos detectar ALT para enviá-lo pelos tubos do terminal) ou direção do pressionamento de tecla
• como códigos de leitura, que têm modificadores e direções, mas são na verdade apenas representações de _localizações de chaves físicas_

Quando você começar a procurar abaixo do nível do sistema operacional, os códigos de leitura _são_ o modo “o mais bruto possível”. No entanto, eles exigem um pouco de preparação antes de serem passados ​​para aplicativos que exigem entrada de texto. (Edite para adicionar :) Os aplicativos de terminal realmente preferem sua entrada como texto. Não podemos enviar códigos de digitalização por meio de uma conexão SSH! Mesmo se pudéssemos, o destinatário então _se_precisaria entender o layout do teclado para fazer a tradução. Provavelmente, as máquinas sem cabeça não têm um layout de teclado. (/editar)

Se fosse tão fácil como “pegar o caracter literal que eles pressionaram e enviar”, você tem que confiar que faríamos exatamente isso. Não criamos soluções malucas porque somos pessoas malucas! :sorriso:

Bem, eu estava por perto, embora não tivesse muita ideia de como lidar com o fluxo de entrada naquela época.

No entanto, o Linux funciona com os códigos-chave brutos por padrão, então isso não é problema. Seu exemplo de conexão ssh é, entretanto, falho, já que o ssh nunca é executado diretamente pelo aplicativo de terminal - há um shell dentro (ou uma abstração de sistema operacional inteira como WSL) que é responsável pelo que chega ao shell.

Se o que você está afirmando estiver certo, todos os aplicativos já escritos para Windows (rodando sobre o explorer) teriam que implementar seu próprio manuseio intrínseco do teclado. Eles não sabem. Porque é feito o upstream e o downstream.

Eu olhei para o código e tive minha parte de "SMH". Posso fazer melhor? Com tempo, provavelmente. Posso me dar ao luxo de reclamar disso? Dado que não tenho tempo para fazer isso sozinho - provavelmente não.

Ainda achei que vale a pena mencionar que ele está sendo sobrecarregado da maneira como está, e causará problemas posteriormente (provavelmente mais cedo ou mais tarde).

Bem, eu estava por perto, embora não tivesse muita ideia de como lidar com o fluxo de entrada naquela época.

No entanto, o Linux funciona com os códigos-chave brutos por padrão, então isso não é problema. Seu exemplo de conexão ssh é, entretanto, falho, já que o ssh nunca é executado diretamente pelo aplicativo de terminal - há um shell dentro (ou uma abstração de sistema operacional inteira como WSL) que é responsável pelo que chega ao shell.

WSL não faz nenhum tipo específico de tradução. conhost.exe ou terminal Windows (ou terminal Gnome se você executar um aplicativo gráfico por meio de, digamos, XMing) faz a tradução adequada para enviar para o pty. E mesmo a concha ... não é a própria concha que faz a maior parte do trabalho. É o driver do terminal e o aplicativo na extremidade mestre (que, novamente, é conhost.exe, Terminal do Windows, talvez Cygwin Terminal se você preferir, e os aplicativos de terminal do Linux).

Se o que você está afirmando estiver certo, todos os aplicativos já escritos para Windows (rodando sobre o explorer) teriam que implementar seu próprio manuseio intrínseco do teclado. Eles não sabem. Porque é feito o upstream e o downstream.

A maioria dos aplicativos não se preocupa com a entrada bruta do teclado, na verdade. Isso é tratado por meio de algumas bibliotecas Win32 de maneiras que apresentam perdas inerentes. Eles não usam entrada de teclado bruta diretamente. A maioria dos aplicativos só se preocupa com os personagens, além dos jogos que podem se preocupar exatamente com a entrada do layout físico. De qualquer maneira funciona muito bem.

Eu olhei para o código e tive minha parte de "SMH". Posso fazer melhor? Com tempo, provavelmente. Posso me dar ao luxo de reclamar disso? Dado que não tenho tempo para fazer isso sozinho - provavelmente não.

Ainda achei que vale a pena mencionar que ele está sendo sobrecarregado da maneira como está, e causará problemas posteriormente (provavelmente mais cedo ou mais tarde).

Eu sugiro que você dê uma olhada no Gnome-Terminal, o análogo do Linux, e verifique se é mais simples ou mais complexo. Suspeito que seja mais complexo, pois o X é realmente mais estranho do que o GDI32 ou qualquer API de janelas em uso.

Existe uma regressão de 0.2.1831.0 ?
No teclado dinamarquês, o Windows Terminal Preview v0.3.2142.0 não responde ao AltGr.

Terminal Windows (visualização)
Versão: 0.3.2142.0
Microsoft Windows 1903 [Versão 10.0.18362.267]

Eu tenho teclado dinamarquês e v0.3.2142.0 Windows build 10.0.18362.239 É um sistema operacional em inglês sem pacotes de idiomas. Os caracteres especiais Alt Gr funcionam aqui, a sequência Ctrl + Alt não

Eu tenho teclado dinamarquês e v0.3.2142.0 Windows build 10.0.18362.239 É um sistema operacional em inglês sem pacotes de idiomas. Os caracteres especiais Alt Gr funcionam aqui, a sequência Ctrl + Alt não

Meus Os: Win10 Home 1903 Build 10.0.18362.267
Sistema operacional dinamarquês com pacote de idioma americano adicional instalado, embora o pacote de idioma dinamarquês seja o padrão.
Hmm - Versão 10.0.18362.267 vs 10.0.18362.239 - há uma pista aí? !!!

Meus Os: Win10 Home 1903 Build 10.0.18362.267
Sistema operacional dinamarquês com pacote de idioma americano adicional instalado, embora o pacote de idioma dinamarquês seja o padrão.
Hmm - Versão 10.0.18362.267 vs 10.0.18362.239 - há uma pista aí? !!!

Para obter todos os detalhes:
Eu estou em
Win 10 Enterprise en-US 1903 compilação 18362.239
Teclado dinamarquês, sem pacote de idioma

Apenas tentei fazer o login em uma conta com o pacote de idioma dos EUA como padrão - instalei o terminal lá e mudei para o teclado dinamarquês para ver se o pacote de idioma escolhido teve alguma influência, mas sem sorte.

Não sei se isso pode ser uma pista para alguém que sabe, mas antes de atualizar para 1903 de 1809, o teclado virtual ( c:\windows\system32\osk.exe ) mostrou o mesmo comportamento em todos os aplicativos conhost, cmd.exe, ubuntu / wsl e powershell.exe (ignorando o AltGr), mas em 1903 isso parece corrigido.

Posso confirmar que _algumas_ sequências AltGr não funcionarão.
AltGr Q (= @ ) funciona para mim, enquanto por exemplo AltGr 8 (= [ ) não.

Eu criei a versão da loja v0.3.2142.0 localmente para depurar esse problema. Como não consegui descobrir como construir o AzureConnector, tive que excluí-lo: https://gist.github.com/lhecker/320662cb3fda70af1ca58eabf9f2579a
👉 Acontece que minha v0.3.2142.0 construída localmente funciona bem. Todas as sequências AltGr funcionam corretamente.
Apenas a versão de armazenamento do Terminal não. O AzureConnector poderia ser o culpado aqui, já que eu o excluí? (Quer dizer, eu duvido que seja o caso, mas só para ter certeza ...)

@ DHowett-MSFT @miniksa Você (ou alguém) pode verificar novamente a versão Store da v0.3.2142.0 e compará-la com as construídas localmente?

Eu tenho o mesmo problema. O terminal não pode ser usado com esse problema, pois AltGr é obrigatório. E por que esse tópico está fechado? Deve ser uma questão de alta prioridade.

E por que esse tópico está fechado?

@MasMedIm Você pode perceber, ao

@lhecker isso é muito incomum. O conector do Azure não deve ter nada a ver com isso, pois está em uma camada diferente (conexão, não controle) ... mas isso é interessante de qualquer maneira.

Você (ou alguém) pode verificar novamente a versão Store da v0.3.2142.0 e compará-la com as construídas localmente?

A versão que tenho em que o caractere especial AltGr funciona é a versão da loja

AltGr ( ~#{[|`\^@]}¤€ ) funciona bem aqui com um teclado francês, Windows 10 versão 1903 compilação 18362.267 e Windows Terminal Preview 0.3.2142.0

@ sba923 Também tenho um teclado francês e a mesma versão do Windows. As combinações AltGr que não funcionam são: & ~ # {[| `\ ^ € ù \
Meu terminal também é baixado da loja. Vou tentar construí-lo no local para ver.

Só para elaborar minha situação, - algumas combinações AltGr + Tecla realmente funcionam, enquanto outras não.

Não funciona:

| Chave | Tecla AltGr +, esperada: |
| ----- | ----------------------- |
| '2' | '@' |
| '3' | '£' |
| '4' | '$' |
| '7' | '{' |
| '8' | '[' |
| '9' | ']' |

Trabalho:

| Chave | Tecla AltGr +, esperada: |
| ----- | ----------------------- |
| '0' | '}' |
| '´' | '|' |
| '<' | '\' |
| '¨' | '~' |
| 'e' | '€' |

Nota: '´', '¨' são tipos de chaves mortas.

Sistema: Windows 10 64 bits Home 1903 Build 10.0.18362.267
Terminal Windows: Preview v0.3.2142.0 - Versão da loja
Layout do teclado: dinamarquês.

@MasMedIm , @ sba923 , @lhecker - Suas versões do Windows Home são como as minhas?
Edit: Esqueça minha pergunta. Eu estava prestes a começar uma caça ao ganso ;-), mas @lhecker parece ter resolvido a regressão!

@ DHowett-MSFT @ henrik-jensen et. al .: eu encontrei a causa da regressão. ¯ \ _ (ツ) _ / ¯
... e isso faz de todos nós aqui um bando de idiotas por notarmos antes. 😂

O novo profiles.json contém atalhos do tipo Ctrl+Alt+[0-9] para pular rapidamente para a guia 1-10.
Se você remover esses atalhos de seu arquivo de configurações ( Ctrl , ) a regressão será corrigida.
Certas combinações como AltGr E para € infelizmente nunca funcionaram ainda e alguém tem que tomar o tempo necessário para consertar isso.

Devido à maneira como as APIs do Windows antigas funcionam, será difícil diferenciar de forma confiável entre os atalhos Ctrl Alt e os pressionamentos de tecla AltGr reais, mas vou verificar se a situação pode ser melhorada de alguma forma.

@lhecker 🥇 👍
Confirmado. Jubii

Certas combinações como AltGr E para € infelizmente nunca funcionaram ainda e alguém tem que tomar o tempo necessário para consertar isso.

AltGr E -> '€' funciona no meu layout de teclado dinamarquês. Vou tentar adicionar um layout alemão no meu para ver se é reproduzível na minha configuração.

Que tal apenas morder a bala? Manter o antigo CMD.EXE disponível para aplicativos legados (DOS) e projetar o novo Terminal apenas para o futuro? Não que a compatibilidade com versões anteriores não seja ótima - mas às vezes você simplesmente _tem_ que cortar os laços ...

@lhecker 🥇 👍
Confirmado. Jubii

Certas combinações como AltGr E para € infelizmente nunca funcionaram ainda e alguém tem que tomar o tempo necessário para consertar isso.

AltGr E -> '€' funciona no meu layout de teclado dinamarquês. Vou tentar adicionar um layout alemão no meu para ver se é reproduzível na minha configuração.

Alemão ~ Kezboard ~ ups instalados, teclado :-) * e AltGr E -> '€' funcionam nesta configuração.

Editar: * 'z' / 'y' são trocados nos teclados alemão / dinamarquês.

O novo profiles.json contém atalhos do tipo Ctrl+Alt+[0-9] para pular rapidamente para a guia 1-10.

Por alguma razão, esses atalhos são alt + [0-9] no meu arquivo de configurações e, portanto, não tive o problema

Algumas perguntas agora me ocorrem:

• @lhecker Talvez devêssemos criar um novo problema para a regressão para descoberta / histórico e você pode adicionar sua solução de patch a isso? Edit: Ótimo - @lhecker fez uma solicitação de pull # 2235
• Gostaria de saber onde o padrão ~ settings.json ~ profiles.json é gerado. Não é um recurso, então presumo que esteja codificado em algum lugar. Editar: encontrei CascadiaSettings.cpp L369
• Quais atalhos alternativos devem ser escolhidos. Talvez aqueles que @saadanerdetbare tem em seu ~ settings.json ~ profiles.json (eram o padrão no pré 0.3.2142.0? Edit: Parece que sim - # 2014)

@lhecker @ henrik-jensen isso faria sentido. Eu instalei da loja logo após ser lançado lá e fiz algumas alterações em profiles.json Então, se a atualização não substituiu o arquivo porque era personalizado e não padrão, eu não obtive os atalhos Ctrl + Alt

@ DHowett-MSFT @ henrik-jensen et. al .: eu encontrei a causa da regressão. ¯_ (ツ) _ / ¯
... e isso faz de todos nós aqui um bando de idiotas por notarmos antes. 😂

O novo profiles.json contém atalhos do tipo Ctrl+Alt+[0-9] para pular rapidamente para a guia 1-10.
Se você remover esses atalhos de seu arquivo de configurações (Ctrl,) a regressão será corrigida.
Certas combinações como AltGrE para € infelizmente nunca funcionaram ainda e alguém tem que tomar o tempo necessário para consertar isso.

Devido à maneira como as APIs do Windows antigas funcionam, será difícil diferenciar de forma confiável entre os atalhos CtrlAlt e os pressionamentos de tecla AltGr reais, mas vou verificar se a situação pode ser melhorada de alguma forma.

Ty para a resposta, na verdade foram as configurações de Ctrl + Alt + [0-9]

@saadanerdetbare , Sim, foi alterado de suas configurações para as novas aqui # 2014 por @ zadjii-msft

Confirmo que os novos atalhos quebram o AltGr ( ~#{[|`\^@]} ) no meu teclado francês.

O motivo pelo qual alguns de nós não viram a regressão está relacionado ao fato de a atualização 0.3 não substituir um profiles.json , documentado no Windows Terminal Preview v0.3 Release :

Nota: Se você instalou o Terminal anteriormente antes desta versão, essas combinações de teclas só aparecerão por padrão depois que você excluir o profiles.json e permitir que ele seja regenerado. Você pode salvar seu profiles.json original em outro lugar e copiar suas personalizações ou apenas adicionar essas combinações de teclas manualmente. Estamos cientes de que não é uma experiência ideal e estamos trabalhando para melhorá-la.

Pode-se usar ctrl + alt + shift + _digit_, embora não seja muito fácil de digitar ...

@ henrik-jensen eu abri # 2235.

@thorsig Você já foi informado sobre o estado das coisas no cenário da API do Windows.
Especialmente dado que, por exemplo, bash no Linux (como a maioria dos shells que você pode querer usar no Windows no futuro) _não_ recebe códigos de tecla brutos, mas sim texto regular infundido com sequências de escape. Sequências de escape que seu terminal precisa gerar a partir de eventos de teclado. Seu shell do Linux _não_ lida com códigos-chave brutos. Seu terminal sim.
Antes de continuar, você deve primeiro entender como o xterm e o vt100 (e posteriores) funcionam.
E aliás: os códigos de tecla no Linux também são apenas uma abstração virtual (! = Bruta) sobre os códigos de acesso do seu teclado - consulte keymaps.5 . A única diferença é que no Windows foi decidido há muito tempo que Ctrl + Alt é o mesmo que AltGr, porque alguns teclados não tinham as teclas AltGr, mas ainda se desejava poder pressionar AltGr de alguma forma. As pessoas que decidiram isso podem ter mais de 60 anos hoje em dia. Alterar isso não é trivial e tem apenas um benefício insignificante (já que você pode detectar pressionamentos de tecla AltGr na prática, de qualquer maneira).

Confirmo que os novos atalhos quebram o AltGr ( ~#{[|`\^@]} ) no meu teclado francês.

O motivo pelo qual alguns de nós não viram a regressão está relacionado ao fato de a atualização 0.3 não substituir um profiles.json , documentado no Windows Terminal Preview v0.3 Release :

Nota: Se você instalou o Terminal anteriormente antes desta versão, essas combinações de teclas só aparecerão por padrão depois que você excluir o profiles.json e permitir que ele seja regenerado. Você pode salvar seu profiles.json original em outro lugar e copiar suas personalizações ou apenas adicionar essas combinações de teclas manualmente. Estamos cientes de que não é uma experiência ideal e estamos trabalhando para melhorá-la.

Pode-se usar ctrl + alt + shift + _digit_, embora não seja muito fácil de digitar ...

É mais fácil usar alt + _digit_ e é semelhante aos atalhos do gnome-terminal.
Funciona no meu teclado francês.

Se você usar Alt + dígito , esteja ciente de que não será possível enviar essas teclas para um aplicativo de console.

: tada: Este problema foi resolvido em # 2235, que agora foi lançado com sucesso como Windows Terminal Preview v0.3.2171.0 .: tada:

Links úteis:

• Notas de Lançamento
• Download da loja

AltGr ( ~#{[|`\^@]}¤€ ) funciona bem aqui com um teclado francês, Windows 10 versão 1903 build 18362.267, Windows Terminal Preview 0.3. 2171 .0 e os atalhos de alternância de guias definidos como Ctrl+Alt+digit .

Bom trabalho!

Obrigado pela confirmação!

Você é muito bem-vindo!

Correção 0.3.2171.0 confirmada para meu sistema - teclado dinamarquês Win10 Home 1903 compilação 10.0.18362.267.
Excluí meu profiles.json para obter as configurações padrão e agora AltGr também funciona para uma nova instalação (presumo).
Excelente trabalho @lhecker e todos os outros envolvidos.

Olá, acho que tenho esse problema na versão 0.7.

Não consigo inserir a barra no meu teclado nem usando o teclado numérico ou AltGr + Q (teclado ABTN2 brasileiro de um laptop Samsung que não tem a tecla ponto de interrogação / barra).

Edit: Não consigo inserir nenhuma tecla AltGr.

Após remover uma versão anterior do PSReadline eveything está funcionando agora.

FWIW, escrevi os scripts do PowerShell anexados para verificar quais versões do PSReadline estão em meu sistema / qual está ativa.

CheckPSReadLineStatus.zip

HTH

Para corrigir o mesmo problema relatado pelo beppler, faça:

Após remover uma versão anterior do PSReadline eveything está funcionando agora.

Na Sessão PowerShell elevada, faça:

Install-Module -Name PowerShellGet -Force
Exit

Na sessão de cmd elevada, faça:
powershell -noprofile -command "Install-Module PSReadLine -Force -SkipPublisherCheck -AllowPrerelease"

Qual é a situação desse problema?
Porque olhando para os problemas vinculados parece corrigido, mas ainda não está funcionando para mim. Para imprimir o caractere ~ em um layout de teclado italiano, estou acostumado a usar Alt + 126, mas isso tem um comportamento diferente dependendo do tipo do terminal, mas em nenhum deles eu consigo obter o caractere ~ impresso, enquanto faz diretamente no shell subjacente (git / cmd / powershell / wsl não embutido no terminal do Windows) funciona como esperado

Isso está acontecendo comigo com a versão mais recente do terminal do Windows, no momento em que escrevo:

Windows Terminal (Preview)
Version: 0.8.10091.0)

@ilmax I quebrei a entrada Alt + teclado numérico em # 3117. Agora que o # 3117 foi fundido e o problema associado corrigido, poderíamos trabalhar na reintrodução da entrada do teclado numérico na base de código.
Eu faria isso um comportamento opcional e configurável, porque tenho quase certeza de que a maioria dos usuários em potencial do aplicativo Terminal não se beneficiará mais com isso. O aplicativo deve, portanto, enviar por padrão ao shell todas as entradas de teclado possíveis para que você possa configurar atalhos de teclado mais avançados, etc.
Implementar isso deve ser um pouco mais fácil assim que o # 4192 for mesclado. Você teria que adicionar a lógica adicional aqui e verificar se a tecla Alt (e apenas a tecla Alt) está sendo pressionada em states , enquanto a tecla v deriva do teclado numérico em oposição às teclas numéricas regulares . Sinta-se à vontade para enviar um PR a qualquer momento! 🙂

@lhecker obrigado pela resposta rápida, eu só queria saber o estado disso porque todos os problemas que encontrei foram fechados, mas o problema ainda está lá.
Não tenho certeza se vou fazer um PR sobre isso, eu nunca li o código antes 😄 então eu realmente não sei por onde começar, apesar da sua sugestão.

Eu só queria saber como consertar meu fluxo de trabalho para git rebase -i porque agora tenho que abrir algo como o notepad ++, digitar o caractere ~, copiá-lo e colá-lo no terminal.

Só para eu entender: você está em um tópico sobre AltGr com uma pergunta sobre sequências _alt + numpad_? Pode ser por isso que todos os threads que você encontrou foram fechados: o problema AltGr foi corrigido.

Eu acredito que temos um problema separado rastreando problemas de entrada alt + teclado numérico.

Sim, você está certo, desculpe a confusão. Acho que # 657 pode ser o correto