Mise à jour: la même chose se produit avec tous les chiffres lorsqu'ils sont combinés avec Alt Gr .

Vous savez, c'est probablement sur moi. Nous n'obtenons probablement pas vkey correctement pour les combos AltGR quelque part dans TermControl.cpp, lorsque nous obtenons l'événement KeyDown.

Un peu sans rapport, mais quel logiciel avez-vous utilisé pour obtenir un enregistrement avec les touches sur lesquelles vous avez appuyé sur le gif

@watermelonpizza J'ai utilisé Carnac pour afficher les pressions sur les touches et ScreenToGif pour capturer la fenêtre.

Oh carnac, génial merci! J'ajouterai ça à ma liste de goodies :)

Je pense que c'est un double de # 487.

Oups, on dirait que la main gauche ne sait pas ce que fait la main droite, et je viens de créer un lien circulaire en double.

Peut confirmer ce problème sur Windows version 10.0.18362.30 avec une disposition de clavier hongrois. Le comportement est différent, selon la console que j'utilise:

• cmd: il écrit juste le caractère mais en majuscules
• PowerShell: ne fait rien du tout
• git bash: n'écrit rien, mais joue le bip par défaut

@ zadjii-msft J'ai trouvé votre commentaire (?) AltGr dans terminalInput.cpp .
Sur mon clavier allemand, l'état de la touche de contrôle est LEFT_CTRL_PRESSED | LEFT_ALT_PRESSED au lieu de LEFT_CTRL_PRESSED | RIGHT_ALT_PRESSED apparemment attendu.
De plus, la touche virtuelle enfoncée est par exemple "Q" au lieu d'un caractère unicode déjà transformé.

Ainsi j'ai remplacé ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
avec...

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

...et il fonctionne! Pour l'instant. 😅 Il déléguera la gestion à WM_CHAR / _CharacterHandler qui, selon Google, est plus robuste pour la gestion AltGr. (?) (Je ne suis pas encore très familier avec la programmation Windows.)
Que pensez-vous de cela? Dois-je soumettre un PR?

@lhecker Génial! Maintenant, c'est réellement utilisable 🎉

@lhecker Oui, veuillez soumettre un PR. Sur les claviers allemands, je ne peux pas saisir le tuyau pour le moment, ce qui rend le terminal un peu difficile à utiliser.

J'ai l'impression que mon changement est incorrect. Il doit y avoir une raison pour laquelle tous les caractères ne sont pas gérés par WM_CHAR n'est-ce pas?
Pour cette raison, j'aimerais d'abord attendre les commentaires de @ zadjii-msft ou @ DHowett-MSFT. Je pense? 😅

La cause réelle est dans Terminal.cpp

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

Vous pouvez voir que le RIGHT_ALT_PRESSED n'est jamais correctement détecté ici, ce qui provoque le retour de keyEvent.IsAltGrPressed dans TerminalInput :: HandleKey false.

Btw, l'état des modificateurs est acquis par _GetPressedModifierKeys () dans TermControl :: _ KeyDownHandler (). au lieu d'une valeur booléenne, vous pouvez passer l'état des modificateurs directement dans SendKeyEvent et déterminer si le ctrl gauche / droite, alt gauche / droite, décalage gauche / droite est pressé plus tard.

Et il y a déjà défini comme suit dans VirtualKey, qui peut être utilisé dans TermControl :: _ GetPressedModifierKeys ()

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

Ah belle prise @sagood!
Malheureusement, la résolution de ce problème ne sera pas suffisante pour autant que je puisse le voir ...
TerminalInput::HandleKey suppose apparemment que lorsque AltGr est pressé, le système d'exploitation a déjà "prétraduit le UnicodeChar à la valeur alternative appropriée", ce qui n'est pas le cas par exemple AltGr + Q (= @) sur un clavier allemand.
Cela signifie que la logique actuelle autour de IsAltGrPressed() est déjà un peu défectueuse.

@lhecker J'ai essayé d'utiliser RIGHT_ALT_PRESSED à la place pour initialiser les modificateurs DWORD. J'ai testé AltGr + '+' (= ~), il sera correctement affiché dans la console.
AltGr + <(= |) fonctionne également.

Mais AltGr + Q ne semble pas fonctionner en effet. bizarre.
AltGr + E (= €) ne fonctionne pas non plus.

En configurant un nouveau c # UWP, j'ai observé que la séquence de touches lors de l'utilisation d'AltGr est la suivante,

Menu
Control
Q

(prenez AltGr + Q comme exemple)

Un débogage plus poussé montre que si vous forcez le programme à exécuter la première branche de condition de TerminalInput :: HandleKey à partir de terminalInput.cpp comme indiqué ci-dessous,

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 fonctionnera.

Que diriez-vous AltGr + ß pour \ sur le clavier allemand, que l'on a le même problème

Toutes les combinaisons de touches AltGr sont affectées par le même problème.

Des progrès à ce sujet? J'ai pu reproduire le comportement, mais je ne suis pas sûr de savoir comment le cas AltGr devrait réellement être traité. Au cas où cela aiderait, voici quelques éléments que j'ai examinés:

• J'ai vérifié que, sur un clavier allemand, AltGr est bien traduit en Left_CTRL && LEFT_ALT , testé pour CMD, PS et WSL
• Il semble que le bogue soit lié à des tests non réussis. Les tests suivants échouent pour moi lors du passage à un clavier allemand mais réussissent sur le clavier anglais:
  
  
  
  • InputEngingeTest:C0
  
  
  • InputTest::TerminalInputModifierKeyTests#metadataSet3 jusqu'à et y compris set10
  
  

@lhecker Par curiosité, j'ai appliqué votre première idée de remplacer isAltGrPressed() par isAltPressed() && isCtrlPressed() , et j'ai vérifié qu'elle:

• fonctionne pour CMD y compris @ et €, mais pas en PS ou WSL
• ne corrige pas les tests non réussis
• mais à la place casse MouseInputTest::SgrModeTests#metadataSet20 pour le clavier anglais.

Même si je ne suis pas allé très loin dans la réduction du problème, j'ai pensé que l'information pourrait être utile.

C'est très intéressant @MattKuhr. @ et € fonctionnent pour moi à la fois dans PowerShell et WSL. 🤔
(Juste pour être sûr à 100% - Ceci est mon diff sur le maître actuel 67f68eb.)

C'est en effet, j'ai mis à jour le master actuel et l'ai testé à nouveau. Maintenant, les caractères spéciaux fonctionnent, sauf pour € dans PS.

Je ne suis pas sûr de la cause du comportement que j'ai observé plus tôt, les mêmes modifications de code ont été utilisées. Je commence à penser que j'ai peut-être gâché quelque chose avec le déploiement pendant les tests, bien que j'aie testé plusieurs fois, ou que certaines mises à jour Windows installées entre-temps aient eu un effet.

Il s'agit d'une capture d'écran avec le clavier allemand défini lors du test sur le maître actuel:

Je l'ai testé à la fois sur Debug et Release (x64), Win 10.0.18362.116. J'ai également essayé de changer la langue du système, ce qui n'a eu aucun effet. Cela semble un peu étrange, que seulement dans ce cas précis, l'euro ne soit pas traduit correctement.

Dites, cela commence-t-il à fonctionner dans PowerShell si vous commencez par Remove-Module PSReadline ? (Ne vous inquiétez pas: cela n'affectera que votre session en cours.) Si c'est le cas, nous avons quelques idées!

@ DHowett-MSFT Je l'ai testé avec une version de la vérification principale d'hier sans modification de la disposition du clavier allemand en 18362.113 (le paramètre de langue est l'anglais)

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

Pour les caractères normaux, Alt Gr fonctionne comme shift. Tout autre caractère est laissé sur la valeur sans modificateur.

@ DHowett-MSFT En fait 😃

Les autres touches continuent de fonctionner. De plus, auparavant, le minuscule 3 était écrit comme un 3 normal, maintenant il apparaît correctement, comme vous pouvez le voir dans la capture d'écran ci-dessous.

Salut,

Juste ici pour dire que cela affecte également la disposition QWERTY finlandais, rendant toutes les combinaisons AltGr comme @, |, {}, [], ~, \ etc. inutilisables.

Tout cela semble fonctionner correctement avec le correctif de @lhecker !

Bonjour, cela fonctionne également pour la disposition du clavier français Azerty. Merci @lhecker

Problème avec les combinaisons Alt Gr, par exemple «Alt Gr + <» (barre oblique inverse, mais donne «<») sur un clavier suisse allemand.

J'ai mis à jour le titre de ce numéro pour rendre plus évident aux passants ce qu'il suit.

@ zadjii-msft J'ai trouvé votre commentaire (?) AltGr dans terminalInput.cpp.
Ainsi j'ai remplacé ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
avec...
if (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
retourner faux;
}
...et il fonctionne! Pour l'instant. 😅

Ce changement me donne également un AltGr utilisable sur mon clavier français. Testé jusqu'à présent avec CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (tous deux avec le PSReadline 2.0.0beta4 non officiel dont on a besoin pour travailler dans VScode)

Ce changement me donne également un AltGr utilisable sur mon clavier français. Testé jusqu'à présent avec CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (tous deux avec le PSReadline 2.0.0beta4 non officiel dont on a besoin pour travailler dans VScode)

J'ai vérifié ma version PSReadline et mis à jour de 2.0.0 à 2.0.0-beta4 et cela a fait l'affaire, maintenant € et ³ fonctionnent également correctement dans PS, 5.1 et 6.2.1. 😄

Bien que j'aie trouvé un autre bogue qui semble également être lié à PSReadline, mais pas directement à AltGr ou à la disposition du clavier. Comme vous pouvez le voir ci-dessous, dans le terminal CTRL 2 est traduit en " et CTRL 7 (sur la disposition GER, aux États-Unis, c'est CTRL / ) en ^_

Pour le premier cas, la suppression de PSReadline fait l'affaire, pour le second, ce n'est pas le cas. J'ai essayé les autres touches de nombre et de caractères spéciaux, mais ces deux étaient les deux seules instances que j'ai pu trouver jusqu'à présent. Le comportement est identique pour 5.1 et 6.2.1. PSReadline est 2.0.0beta4.

Devrions-nous ouvrir un numéro distinct pour cela?

Je vois également des problèmes liés sur un clavier portugais (Portugal).
Attendu: Alt Gr + 2/3/4/7/8/9/0 devrait afficher @ £ § {[]}, Alt Gr + e devrait obtenir €

Terminal Windows:
-PS Core: Alt Gr + digit déclenche PSReadline DigitFunction, sauf 7 sorties ^ _
-PS Core: Alt Gr + € ne fait rien
-Windows Powershell: identique à PS Core
-CMD: Alt Gr + digit renvoie le chiffre, sauf 7 sorties ^ _
-CMD: Alt Gr + e sorties E

Console intégrée:
PS Core: sortie Alt Gr + 2/3/4/7/8/9/0 @ £ § {[]}, Alt Gr + E ne fait rien
Windows PowerShell: identique à PS Core
CMD - Tous les travaux

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

Une solution de contournement éprouvée lorsque les combinaisons de touches «Alt Gr» ne fonctionnent pas consiste à utiliser le code Alt + NumPad .

Mais cela ne fonctionne pas non plus!

657 "Alt + Numpad ne fonctionne pas"

Je conseillerais que quiconque s'adresse à celui-ci aborde également celui qui est étroitement lié.

Je peux également le vérifier pour le clavier islandais. Nous utilisons AltGr pour écrire ceux-ci:
@ | € {[]} \ µ ~ `^

Juste une remarque: ce problème survient dans à peu près toutes les technologies de ligne de commande Microsoft. Cela s'est déjà produit dans OpenSSH , un problème similaire est survenu dans

Chaque fois que j'essaye quelque chose en ligne de commande, des problèmes d'entrée surviennent toujours. Je ne peux toujours pas utiliser PowerShell dans les sessions à distance, car Home-End ne fonctionne pas et ne fonctionne toujours pas via SSH.

D'une manière ou d'une autre, ce triangle terminal-SSH-PSReadline est maudit.

Ici, j'utilise la disposition du clavier PT-BR.

Pour obtenir / j'utilise Alt Gr + Q

Lors de l'utilisation dans Terminal, cela fonctionne comme une commande d'annulation. Il vient de retaper ma dernière commande / lettre / mot

@MathiasMagnus

où aucune des combinaisons AltGr ne fonctionne.

Vous voulez dire qu'aucune des combinaisons AltGr ne fonctionne?

Dites, cela commence-t-il à fonctionner dans PowerShell si vous commencez par Remove-Module PSReadline ? (Ne vous inquiétez pas: cela n'affectera que votre session en cours.) Si c'est le cas, nous avons quelques idées!

Ne fonctionne pas pour moi (mise en page française AZERTY)

alors ..... des nouvelles idées? parce que le correctif ...

`` `c ++
if (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
retourner faux;
}
...

n'a pas fonctionné pour moi <. <

Éditer:

N'est-il pas plus intelligent de détecter la langue principale du clavier, qui est définie sur la machine, puis de faire le rebind-stuff @microsoft ?

@Hedrauta bizarre que le changement de code ne fonctionne pas pour vous. Quelle disposition de clavier utilisez-vous? Que fait Ctrl+Alt+xxx pour vous dans un CMD normal pour des valeurs de xxx qui sont utilisées en combinaison avec AltGr? Autant que je me souvienne, Ctrl+Alt devrait toujours être équivalent à AltGr ...

Donc, pour collecter des données de test: pour moi, le patch de @lhecker semble fonctionner

Terminal | Alt Gr + ß? \ | Strg + Alt + ß? \
- | - | -
Héritage cmd.exe | \ | \
Héritage pwsh.exe | \ | \
Terminal Windows, master , cmd.exe | ß | ß
Terminal Windows, master , pwsh.exe | _ (rien) _ | _(rien)_
Terminal Windows, master + Patch par @lhecker , cmd.exe | \ | \
Terminal Windows, master + Patch par @lhecker , pwsh.exe | \ | \

même résultat que dans https://github.com/microsoft/terminal/issues/521#issuecomment -501148984
avec le Patch de @lhecker

Mais dans pwsh le signe € - ne fonctionne toujours pas sur la mise en page allemande.

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 bizarre que le changement de code ne fonctionne pas pour vous. Quelle disposition de clavier utilisez-vous? Que fait Ctrl+Alt+xxx pour vous dans un CMD normal pour des valeurs de xxx qui sont utilisées en combinaison avec AltGr? Autant que je me souvienne, Ctrl+Alt devrait toujours être équivalent à AltGr ...

Cela ne m'a pas aidé non plus ...
J'ai même essayé de créer ma propre solution de contournement basée sur ce code mais pas de chance jusqu'à présent ...

J'utilise la disposition du clavier PT-BR, en essayant la combinaison suivante:

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

Lors de l'utilisation du terminal Windows
WSL: AltGr + Q = fonctionne comme une commande d'annulation, il réécrit mes derniers caractères tapés.
Powershell, CMD: AltGr + Q = produit ce caractère étrange imprime comme ^_

Éditer:
Pour aider à visualiser:

L'entrée correcte doit être
AltGr + Q = /
AltGr + W = ?
AltGr + [ = ª
AltGr + ] = º

@ renatop7 qu'obtenez -vous avec CtrlAlt au lieu d'AltGr?

@ renatop7 qu'obtenez -vous avec CtrlAlt au lieu d'AltGr?

Le même résultat

Et en dehors du terminal, c'est-à-dire en CMD standard ou Windows Powershell ou Powershell Core? CtrlAlt se comporte-t-il toujours comme AltGr?

Et en dehors du terminal, c'est-à-dire en CMD standard ou Windows Powershell ou Powershell Core? CtrlAlt se comporte-t-il toujours comme AltGr?

Oui, en dehors du terminal, cela fonctionne parfaitement.
En utilisant avec AltGr ou Ctrl + Alt, j'obtiens le résultat attendu.

récupéré il y a 15 minutes: aucun travail du tout
Eh bien, Microsoft travaille-t-il même sur une solution liée à ce problème?

@Hedrauta bizarre que le changement de code ne fonctionne pas pour vous. Quelle disposition de clavier utilisez-vous? Que fait Ctrl+Alt+xxx pour vous dans un CMD normal pour des valeurs de xxx qui sont utilisées en combinaison avec AltGr? Autant que je me souvienne, Ctrl+Alt devrait toujours être équivalent à AltGr ...

Euh, un allemand standard?. voici un écran de son apparence: https://i.imgur.com/mvgHkxi.png
je vais essayer de taper la clé via une macro .... test

c'est comme, mon alt gauche est Shift, pas Alt ...
Résultat essayé
Ctrl + Q ^ Q
CTRL + Alt + QQ
juste Q q
Alt + QQ

Je vais essayer de le gif, mettre à jour le commentaire ensuite
Edit: en essayant de le gif, je me suis rendu compte que ma touche Alt était mal reconnue .... quelqu'un sait, où les touches virtuelles sont définies? va l'examiner aussi;) mais je ne suis pas si expérimenté sur c ++ ou .... tout codage;)

Juste pour moi en tant que cpp noob, j'ai vérifié plusieurs fichiers et j'ai trouvé le
C: \ Program Files (x86) \ Windows Kits \ 10 \ Include \ 10.0.17763.0 \ um \ WinUser.h
Donc ... pour les mises en page allemandes, le VK_Menu n'existe pas, non? nous possédons juste le VK_LMENU, non?
Je vais essayer quelques changements et faire des tests ... je modifierai les résultats plus tard
Edit 1: La construction prend du temps, comme je reconstruis tous mes systèmes oO
Edit 2: après avoir tout construit, cela ne fonctionne pas ... mais j'ai réalisé que VK_RMENU est AltGr, tandis que VK_LMENU est la touche que nous voulons voir enfoncée pour obtenir notre @ ou \
mais VK_MENU semble également fonctionner, mais il est peut-être mal attribué
Cela me déroute un peu, je vérifierai celui-ci après une récupération, une reconstruction et une sieste

Pour la disposition du clavier allemand, c'est encore pire, car Alt Gr + Q qui devrait juste afficher @ , supprime l'entrée de ligne courante.
Cela ne se produit pas avec WSL, et je ne le vois pas configuré pour WT - alors comment cela se produit-il?

Encore un problème:
Clavier: Belge (point) AZERTY, fonctionne en shell normal
Gagnant: 18362.175
Version du terminal: 0.2.1715.0

_Je demande à tout le monde de s'abstenir de dire qu'ils sont également confrontés à ce problème._

À présent, il devrait être clair pour tout le monde que ce problème affecte un grand nombre de combinaisons de touches et peut entraîner un nombre tout aussi important d'effets secondaires inattendus, pour un nombre tout aussi large de langues, de versions Windows, de claviers, etc.
Plus de la moitié des commentaires sont de style #metoo, ce qui n'aide pas du tout à résoudre ce problème et
rend seulement les commentaires utiles moins visibles .
Ce qui manque réellement et serait d'une grande aide, c'est qu'un développeur Windows expérimenté s'attaque à ce problème et soumette un PR.

En attendant, tout le monde capable de compiler ce projet peut se sentir libre de remplacer ce morceau de code: https://github.com/microsoft/terminal/blob/ce4c6d6124c258c676b4eeac61a709c1fb3da459/src/terminal/input/terminalInput.cpp#L392

avec mon correctif expérimental:

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

Cela devrait corriger la plupart des combinaisons de touches pour la plupart des langues du clavier, y compris par exemple des caractères comme @{}[] sur un clavier allemand (ou similaire).

PS: Je ne suis en aucun cas affilié à Microsoft et j'écris ceci parce que je considère personnellement ces commentaires «#metoo» comme trop bruyants / improductifs. 🙂
PPS: Je suis sûr que certains se demandent pourquoi je ne soumets pas de PR moi-même. Pour me citer : "J'ai l'impression que ma modification est incorrecte. Il doit y avoir une raison pour laquelle tous les caractères ne sont pas gérés par WM_CHAR n'est-ce pas?" Cela signifie que je ne sais pas vraiment quels sont les inconvénients du correctif ci-dessus et comment le faire correctement.

PPS: Je suis sûr que certains se demandent pourquoi je ne soumets pas de PR moi-même. Pour me citer: "J'ai l'impression que ma modification est incorrecte. Il doit y avoir une raison pour laquelle tous les caractères ne sont pas gérés par WM_CHAR, n'est-ce pas?" Cela signifie que je ne sais pas vraiment quels sont les inconvénients du correctif ci-dessus et comment le faire correctement.

Une façon de le savoir serait de soumettre un PR et de se faire corriger par l'équipe. C'est un peu exagéré, mais je pense que cela accélérerait les choses.

@NatoBoram 😤👉 # 1436

Notez que lorsque vous utilisez les exemples d'applications, par exemple VtPipeTerm, la touche alt-gr y fonctionne.

@HBelusca VtPipeTerm n'est pas basé sur le nouveau terminal UWP et n'aura donc pas ce problème.
Vous pouvez lire # 1436 pour une explication possible du problème sous-jacent.

@lhecker il n'est pas basé sur Cascadia, mais il utilise la même implémentation de pseudoconsole sous-jacente ... il est donc extrêmement utile de savoir que cela ne s'applique pas à tous les consommateurs de pseudoconsole!

Merci @HBelusca

Les touches spéciales fonctionnent depuis des années dans les terminaux et les applications Windows. Pourquoi avons-nous ce problème maintenant en 2019? Avez-vous complètement réimplémenté le système d'entrée pour le programme terminal? J'espère qu'il était nécessaire de faire cela et de réintroduire les bogues corrigés il y a des années: s. Ce problème était typique sous Linux en raison des pages de code, des mappages de clavier de langue et des touches spécifiques à Windows, mais ce bogue critique se trouve dans la version préliminaire de l'application, qui est disponible dans le magasin et publiée partout.

@ifilgud Il est une version preview disponible dans le magasin pour des raisons de prévisualisation. Ce problème a été trié et il y a aussi un PR soumis pour cela, donc pas besoin de commenter ce problème juste pour se plaindre.

@patriksvensson Je sais que je me plaignais principalement et ce n'est pas "poli", mais je demandais aussi une raison technique pour expliquer la raison d'un bug comme celui-ci. Je m'attendais à avoir des erreurs mineures à corriger dans une version presque terminée (aperçu), mais pas une qui n'aurait pas dû exister dans une évolution d'un terminal, à moins qu'elle ne soit écrite à partir de zéro et testée uniquement en anglais (je suppose que c'est la raison pour laquelle ne pas détecter cela dans la première version alpha). J'ai ouvert le terminal et essayé d'écrire "cd \" comme deuxième commande (la première était "dir"), et cela ne fonctionnait tout simplement pas. En tant que développeur de logiciels, cela m'a beaucoup impacté.

@lhecker jusqu'à présent, tout va bien, après avoir appliqué votre correctif expérimental. Merci beaucoup!!

Merci beaucoup à tous les gens qui l'ont signalé et qui l'ont déjà corrigé. 🌷

À quelle fréquence l'application MS Store sera-t-elle mise à jour?
Alors, quand pouvons-nous nous attendre à ce que des choses soient corrigées dans l'application Store?

J'adorerais travailler avec le terminal mais avec le clavier allemand, vous ne pouvez même pas écrire { } sans altgr. 😅

Vous avez également le même problème pour la disposition du clavier norvégien Bokmål (nb-NO). Impossible de créer [], {} ou $. PowerShell est fondamentalement cassé sans ceux-ci.
Utilisation de UWP / Microsoft Store version 0.2.1715.0 sous Windows 10 1903 18362.175.

Mise en page hu_HU via AltGr: \ | & @ $ ; # <> {} [] Je veux dire à quelle fréquence dois-je ouvrir des accolades, des crochets angulaires ou carrés, une barre oblique inverse, un tube, un signe dollar, une marque dièse, "at", "et", point-virgule ... oh attendez, chaque ligne ?? :)

_Je demande à tout le monde de s'abstenir de dire qu'ils sont également confrontés à ce problème._

À présent, il devrait être clair pour tout le monde que ce problème affecte un grand nombre de combinaisons de touches et peut entraîner un nombre tout aussi important d'effets secondaires inattendus, pour un nombre tout aussi large de langues, de versions Windows, de claviers, etc.
Plus de la moitié des commentaires sont de style #metoo, ce qui n'aide pas du tout à résoudre ce problème et
_only rend les commentaires utiles moins visibles_.

Mise à jour: la même chose se produit avec tous les chiffres lorsqu'ils sont combinés avec Alt Gr .

comment as-tu fait cet enregistrement gif?

@ Karl-WE Regardez plus bas dans le fil.

@ DHowett-MSFT Ce pourrait être une bonne idée de verrouiller ce fil avec un message en bas

Alors que le terminal est très inutilisable pour Powershell tant que ce problème est vivant
Je voudrais proposer une solution de contournement pour Windows 10 1903 pour ceux qui ne peuvent pas s'abstenir jusqu'à ce qu'ils soient corrigés.

Solution de contournement:
utilisez la touche Windows +.
aller à l'onglet des caractères spéciaux sélectionnez votre personnage
passez au terminal et insérez le caractère

Le laisser déverrouillé donne aux gens un espace pour signaler chaque clé individuelle qui ne fonctionne pas afin qu'ils arrêtent de classer des questions individuelles sur chaque clé individuelle qui ne fonctionne pas. Je suis déchiré.

Il peut y avoir plus de cas où les caractères spéciaux ne fonctionnent pas comme prévu. Si je veux créer un caractère @ sur un clavier danois, il y a 3 façons de le faire: Alt Gr + 2, Ctrl gauche + Alt gauche + 2 ou Alt gauche + pavé numérique 64
Les 2 premières options donnent le résultat OP rapporté.
La dernière option fait dans PowerShell:
Onpres Alt gauche + pavé numérique 64 digit-argument: 64
Lors du relâchement Alt gauche: 64 caractères @
En cmd
Onpres Alt gauche + pavé numérique 64: 64
Lors du relâchement Alt gauche: @ résultant en 64@
Dans WSL
Onpres Alt gauche + pavé numérique 64: (arg: 64)
Lors du relâchement Alt gauche: 64 caractères @

Bon point @saadanerdetbare!

Votre problème Alt + Numpad semble provenir du fait que le nouveau terminal (Cascadia) envoie les codes d'échappement appropriés au shell lorsque vous entrez ces codes. Mais simultanément, une autre partie de l'application est _aussi_ de gérer ce cas, en traduisant le code Alt + Numpad en un caractère approprié et en l'insérant dans le shell. Cela conduit à l'effet secondaire amusant de votre caractère @ répété 64 fois (en raison de l'envoi des octets suivants au shell: \x1b6\x1b4@ ).

Vous pouvez essayer cela en ajoutant le code supplémentaire suivant entre ces deux lignes :

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

Cela empêchera Cascadia d'envoyer ces codes d'échappement dans le shell. Ensuite, vos caractères (par exemple @) apparaîtront normalement.
Vous pouvez également supprimer ce bloc de code pour le même effet.

~ @saadanerdetbare Ce serait super génial si vous pouviez créer un problème séparé détaillant votre problème, car il s'agit d'un bogue sans rapport avec la fonctionnalité AltGr. 🙂 ~
👉 # 1401
J'aurais dû d'abord rechercher d'autres problèmes. 🤦‍♂️

PS: Je dois dire cependant que voir une plus grande disponibilité de la communauté à déboguer ces choses elle-même au lieu de compter sur d'autres inconnus me rendrait personnellement très fier. 🙈🙂

@saadanerdetbare attendez de déposer un nouveau numéro, celui-ci est # 1401: sourire:

J'en fais encore l'expérience sur l'application de prévisualisation, j'ai un clavier belge, impossible d'écrire @

@solispauwels, vous devrez attendre la prochaine version (ou créer vous-même la branche principale actuelle pour le moment).

Salut, je viens de tester ce commit sur un clavier allemand et tout fonctionne à part altgr-E qui devrait imprimer le symbole €. Pour être honnête, je n'ai pas vraiment besoin de cela dans un terminal aussi souvent, mais j'ai pensé que je pourrais le mentionner quand même. D'autres comme altgr-m pour µ fonctionnent cependant.

Mise à jour: Je pense que vous pouvez ignorer cela, le symbole € ne fonctionne pas non plus dans un PowerShell standard, donc cela ne semble pas être la faute du terminal, aurait dû vérifier cela plus tôt.

Tout semble fonctionner ici sur un clavier français: AltGr+é"'(-è_çà)=$e donne le ~#{[|`\^@]}¤€ attendu

J'utilise aussi un clavier français (mais je suis en Belgique), et j'ai des problèmes avec l'AltGr +personnages. | # {} @ par exemple ne fonctionne pas. J'utilise la dernière version du Windows Store 0.2.1715.0 sur Windows 10 v1903.

@meuter vous devrez attendre la prochaine version (ou créer vous-même la branche principale actuelle pour le moment).

Le correctif de # 1436 n'est pas encore inclus dans la version préliminaire disponible sur le Microsoft Store

@antoineco @ sba923 merci, c'est ce que j'ai pensé. Je viens de cloner le repo. Dès que mon vs2017 est terminé avec la mise à jour, je vais le reconstruire à partir des sources :-)

Merci à tous de travailler si dur à ce sujet et de remplir nos boîtes de réception de rapports. Merci spécifiquement à @lhecker pour avoir soumis un correctif! Nous venons de le soumettre au magasin avec la version de maintenance v0.2.1831.0. Cela peut prendre un certain temps au magasin pour le traiter.

Nous venons de le soumettre au magasin

Donc, d'après mon expérience avec la publication d'applications sur le Windows Store, cela devrait prendre de 3 jours à 3 semaines 😉

Nous venons de le soumettre au magasin

Donc, d'après mon expérience avec la publication d'applications sur le Windows Store, cela devrait prendre de 3 jours à 3 semaines 😉

Moins de 6h semble-t-il. 😋

Quoi qu'il en soit, sur mon clavier suédois, tout semble bien maintenant. 👍

Fonctionne maintenant avec le clavier allemand 👍

Il fonctionne avec le clavier français avec la version 0.2.1831.0! Merci

Il fonctionne avec le clavier français avec la version 0.2.1831.0! Merci

Confirmé!

Bon travail!

@ DHowett-MSFT La v0.2.1831.0 semble inclure ce correctif mais, pas d'autres correctifs de bogue comme les polices Powerline ou copier / coller des keybings, est-ce normal?

Je confirme que Alt-Gr fonctionne, mais utiliser à la place Ctrl-Alt pour accéder aux mêmes touches du clavier ne fonctionne pas de manière fiable (voire pas du tout).

Dans la version 0.2.1831.0, les combinaisons AltGr fonctionnent désormais avec le clavier finlandais.

@solispauwels les seuls correctifs de la version 0.2.1831.0 sont ceux mentionnés dans les notes de publication.

Sachez que beaucoup de systèmes d'exploitation 1803 ou plus récents peuvent rencontrer un bogue avec la version 11905.1001.4.0 du Windows Store
Le magasin "empile" les applications pour qu'elles soient téléchargées (voir l'image) mais ne télécharge pas les applications, même avec le téléchargement automatique activé et le réseau n'est pas une connexion mesurée.

Les utilisateurs concernés doivent appuyer sur «Rechercher des mises à jour» dans le Microsoft Store pour obtenir éventuellement une application Store fixe et pour lancer tous les téléchargements d'applications en attente.

Je confirme que ce problème sera résolu avec la nouvelle version de Terminal. Merci beaucoup.

Je peux également confirmer que cela est résolu maintenant. Vous souhaiterez peut-être retirer le problème.

Cela fonctionne sauf la touche Euro, qui est AltGr + e, au moins en clavier espagnol. Le reste des combinaisons fonctionne correctement

De @ifilgud

Cela fonctionne sauf la touche Euro, qui est AltGr + e, au moins en clavier espagnol. Le reste des combinaisons fonctionne correctement

Testé sur Windows 10 1903 (18362.175) en utilisant la dernière version le 08/07/2019 avec le clavier AZERTY "Belge (Période)".

Résultat du test:

• toutes les combinaisons disponibles sur mon clavier, y compris le symbole monétaire Euro (€), fonctionnent dans 2 des 3 consoles configurées par défaut dans le terminal Windows: PowerShell Core et 'cmd' (invite de commande Windows)
• Le symbole de l'euro (€) ne fonctionne que dans "Windows PowerShell"
  
  
  
  • Cependant, cela ne fonctionne pas dans la console PowerShell Classic lancée directement à partir de Windows Start également
  
  

Imo, il s'agit d'un nouveau problème lié à Windows PowerShell, non spécifique au terminal Windows hébergeant cette console.

Je confirme l'observation @DeChrist . Par contre, les touches Ctrl-Alt + (Key) ne fonctionnent pas comme prévu (si l'on veut utiliser cette combinaison au lieu de AltGr).

Ici , sur Windows 10 build 18362,175 exécutant Windows Terminal Version Preview 0.2.1831.0, avec un clavier français, AltGr+E ne cède € dans toutes les coquilles suivantes:

• cmd
• Windows PowerShell 5.1
• PowerShell Core 6.2.1
• PowerShell Core 7.0.0-aperçu.1

Est-ce que n'importe qui ayant des problèmes AltGr restants _dans PowerShell_ peut vérifier quelle version de PSReadLine ils exécutent?

$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 pouvez-vous essayer:

1. désactivation de PSReadLine
2. mise à niveau vers la dernière beta4 , voir https://github.com/PowerShell/PSReadLine

• Windows 10 1903
• Terminal Windows 0.2.1831.0
• PowerShell v7 (qui inclut PSReadline 2.0.0-beta4)
• Disposition du clavier QWERTZ allemand

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

Ceci est particulièrement frustrant car il existe un autre bogue lié à mstsc que Microsoft ignore depuis au moins une décennie où AltGr + Q cesse de fonctionner si une session RDP est ouverte. Dans ces situations, Ctrl + Alt + Q fonctionne toujours, tant de gens l'utilisent comme solution de contournement.

Ce que Microsoft DEVRAIT faire est de NE PAS TOUCHER LE FLUX DE CLAVIER.

Le shell (explorer.exe) doit capturer toutes les touches dont il a besoin et transmettre tout le reste en aval.
Terminal.exe devrait finalement attraper UNIQUEMENT Alt-F4 - et peut-être même pas cela - explorer.exe devrait vraiment attraper cela et s'appliquer au processus actif.

Ce qui signifie que Terminal.exe ne doit prendre que le flux clavier et le transmettre au processus enfant actif. Rien d'autre.

CMD.exe [command.com] doit savoir comment attraper ce dont il a besoin, puis transmettre le reste à ses propres enfants.

WSL doit obtenir autant d'entrée brute que possible. NE PAS maltraiter AltGr. Ctrl-Alt et AltGr ne sont PAS les mêmes séquences de clavier. Sous Linux, il existe des raccourcis utilisant ctrl-alt -... qui produisent des résultats différents de AltGr -...

Vous n'avez qu'une occasion de le faire correctement. La première opportunité en près de 40 ans. S'il vous plaît, ne perdez pas cette opportunité - Microsoft, je vous regarde :)

@thorsig ah, si seulement nous vous avions autour de vous lorsque la pile d'entrée Win32 a été architecturée il y a une quarantaine d'années. Malheureusement, nous ne l'avons pas fait, il existe donc deux façons principales de recevoir une entrée au clavier:

• en tant que caractères, sans modificateurs (nous ne pouvons donc pas détecter ALT pour l'envoyer à travers les tuyaux du terminal) ou le sens de la pression des touches
• sous forme de codes de balayage, qui ont des modificateurs et des directions, mais qui ne sont en réalité que des représentations de _ emplacements de clés physiques_

Lorsque vous commencez à regarder au-dessous du niveau du système d'exploitation, les codes de balayage _sont_ le mode «d'entrée aussi brute que possible». Cependant, ils nécessitent un peu de cuisson avant de pouvoir être transmis à des applications nécessitant une saisie de texte. (Modifier pour ajouter :) Les applications de terminal préfèrent vraiment leur saisie sous forme de texte. Nous ne pouvons pas envoyer de codes de scan via une connexion SSH! Même si nous le pouvions, le destinataire aurait alors _ lui-même_ besoin de comprendre la disposition du clavier pour effectuer la traduction. Les machines sans tête n'ont probablement pas de disposition de clavier. (/Éditer)

S'il était aussi simple que «d'obtenir le caractère littéral sur lequel ils ont appuyé et de l'envoyer», vous devez être sûr que nous ferions exactement cela. Nous ne concevons pas de solutions folles parce que nous sommes des fous! :sourire:

Eh bien, j'étais là même si je n'avais peut-être pas vraiment la moindre idée de la manière de gérer le flux d'entrée à ce moment-là.

Cependant, Linux fonctionne avec les codes clés bruts par défaut, ce n'est donc pas un problème. Votre exemple de connexion ssh est cependant imparfait, car ssh n'est jamais exécuté directement par l'application du terminal - il y a un shell à l'intérieur (ou toute une abstraction de système d'exploitation comme WSL) qui est responsable de ce qui atteint le shell.

Si ce que vous dites est juste, chaque application jamais écrite pour Windows (exécutée sur l'explorateur) devrait implémenter sa propre gestion intrinsèque du clavier. Ils ne le font pas. Parce qu'il est pris en charge en amont et en aval.

J'ai regardé le code et j'ai eu ma part de "SMH". Pourrais-je faire mieux? Compte tenu du temps, probablement. Puis-je me permettre de m'en plaindre? Étant donné que je n'ai pas le temps de le faire moi-même - probablement pas.

J'ai toujours trouvé qu'il vaut la peine de le mentionner, il est sur-conçu tel quel, et cela causera des problèmes en aval à un moment donné (probablement plus tôt que plus tard).

Eh bien, j'étais là même si je n'avais peut-être pas vraiment la moindre idée de la manière de gérer le flux d'entrée à ce moment-là.

Cependant, Linux fonctionne avec les codes clés bruts par défaut, ce n'est donc pas un problème. Votre exemple de connexion ssh est cependant imparfait, car ssh n'est jamais exécuté directement par l'application du terminal - il y a un shell à l'intérieur (ou toute une abstraction de système d'exploitation comme WSL) qui est responsable de ce qui atteint le shell.

WSL ne fait aucun type de traduction particulier. conhost.exe ou le terminal Windows (ou Gnome-terminal si vous exécutez une application graphique via, par exemple, XMing) effectue la traduction appropriée à envoyer au pty. Et même la coque ... ce n'est pas la coque elle-même qui fait l'essentiel du travail. C'est le pilote de terminal et l'application à l'extrémité principale (qui, encore une fois, est soit conhost.exe, Windows Terminal, peut-être Cygwin Terminal si vous êtes enclin, et les applications de terminal Linux).

Si ce que vous dites est juste, chaque application jamais écrite pour Windows (exécutée sur l'explorateur) devrait implémenter sa propre gestion intrinsèque du clavier. Ils ne le font pas. Parce qu'il est pris en charge en amont et en aval.

La plupart des applications ne se soucient pas de la saisie brute au clavier. Cela est géré par certaines bibliothèques Win32 de manière intrinsèquement avec perte. Ils n'utilisent pas directement l'entrée clavier brute. La plupart des applications ne se soucient que des personnages, en plus des jeux qui peuvent se soucier exactement de la mise en page physique. Dans les deux cas, cela fonctionne très bien.

J'ai regardé le code et j'ai eu ma part de "SMH". Pourrais-je faire mieux? Compte tenu du temps, probablement. Puis-je me permettre de m'en plaindre? Étant donné que je n'ai pas le temps de le faire moi-même - probablement pas.

J'ai toujours trouvé qu'il vaut la peine de le mentionner, il est sur-conçu tel quel, et cela causera des problèmes en aval à un moment donné (probablement plus tôt que plus tard).

Je vous suggère de vous pencher sur Gnome-Terminal, l'analogue de Linux, et de vérifier s'il est plus simple ou plus complexe. Je soupçonne plus complexe puisque X est en fait plus étrange que le GDI32 ou que l'API de fenêtrage utilisée.

Y a-t-il une régression à partir de 0.2.1831.0 ?
Sur le clavier danois, Windows Terminal Preview v0.3.2142.0 ne répond pas à AltGr.

Terminal Windows (aperçu)
La dernière version: 0.3.2142.0
Microsoft Windows 1903 [Version 10.0.18362.267]

J'ai un clavier danois et v0.3.2142.0 Windows build 10.0.18362.239 C'est un système d'exploitation anglais sans aucun pack de langues. Les caractères spéciaux Alt Gr fonctionnent ici, la séquence Ctrl + Alt ne fonctionne pas

J'ai un clavier danois et v0.3.2142.0 Windows build 10.0.18362.239 C'est un système d'exploitation anglais sans aucun pack de langue. Les caractères spéciaux Alt Gr fonctionnent ici, la séquence Ctrl + Alt ne fonctionne pas

Mon système d'exploitation: Win10 Home 1903 Build 10.0.18362.267
Système d'exploitation danois avec un module linguistique américain supplémentaire installé bien que le module linguistique danois soit par défaut.
Hmm - Build 10.0.18362.267 vs 10.0.18362.239 - y a-t-il un indice? !!!

Mon système d'exploitation: Win10 Home 1903 Build 10.0.18362.267
Système d'exploitation danois avec un module linguistique américain supplémentaire installé bien que le module linguistique danois soit par défaut.
Hmm - Build 10.0.18362.267 vs 10.0.18362.239 - y a-t-il un indice? !!!

Pour obtenir tous les détails:
Je suis sur
Win 10 Enterprise en-US 1903 build 18362.239
Clavier danois, pas de pack de langue

J'ai juste essayé de se connecter sur un compte avec le pack de langue américain par défaut, - installé le terminal là-bas et passé au clavier danois pour voir si le pack de langue choisi avait une influence, mais pas de chance là-bas.

Je ne sais pas si cela pourrait être un indice pour quelqu'un au courant, mais avant la mise à niveau vers 1903 à partir de 1809, le clavier à l'écran ( c:\windows\system32\osk.exe ) a montré le même comportement dans toutes les applications conhost, cmd.exe, ubuntu / wsl et powershell.exe (ignorant l'AltGr) mais en 1903 cela semble corrigé.

Je peux confirmer que certaines séquences AltGr ne fonctionneront pas.
AltGr Q (= @ ) fonctionne pour moi, alors que par exemple AltGr 8 (= [ ) ne le fait pas.

J'ai construit la version du magasin v0.3.2142.0 localement pour déboguer ce problème. Parce que je ne savais pas comment créer AzureConnector, j'ai dû l'exclure: https://gist.github.com/lhecker/320662cb3fda70af1ca58eabf9f2579a
👉 Il s'avère que ma v0.3.2142.0 construite localement fonctionne très bien. Toutes les séquences AltGr fonctionnent correctement.
Seule la version magasin du terminal ne le fait pas. AzureConnector pourrait-il être en faute ici, puisque je l'ai exclu? (Je veux dire, je doute que ce soit le cas, mais juste pour être sûr ...)

@ DHowett-MSFT @miniksa Pouvez-vous (ou quelqu'un) revérifier la version Store de v0.3.2142.0 et la comparer avec celles construites localement?

J'ai le même problème. Le terminal n'est pas utilisable avec ce problème car AltGr est un must. Et pourquoi ce fil est fermé? Ce devrait être une question prioritaire.

Et pourquoi ce fil est fermé?

@MasMedIm Vous remarquerez peut-être en y pensions que ce bogue était corrigé et que nous avons même publié une version avec le correctif.

@lhecker c'est très inhabituel. Le connecteur Azure ne devrait rien avoir à voir avec cela car il se trouve dans une couche différente (connexion, pas de contrôle) ... mais c'est intéressant quand même.

Pouvez-vous (ou quelqu'un) revérifier la version Store de v0.3.2142.0 et la comparer avec celles construites localement?

La version que j'ai où le caractère spécial AltGr fonctionne est la version du magasin

AltGr ( ~#{[|`\^@]}¤€ ) fonctionne bien ici avec un clavier français, Windows 10 version 1903 build 18362.267 et Windows Terminal Preview 0.3.2142.0

@ sba923 J'ai aussi un clavier français et la même version Windows. Les combinaisons AltGr qui ne fonctionnent pas sont: & ~ # {[| `\ ^ € ù \
Mon terminal est également téléchargé depuis la boutique. Je vais essayer de le construire en local pour voir.

Juste pour élaborer sur ma situation, - certaines combinaisons AltGr + Key fonctionnent réellement tandis que d'autres ne le font pas.

Ne marche pas:

| Clé | AltGr + Key, attendu: |
| ----- | ----------------------- |
| «2» | '@' |
| «3» | «£» |
| «4» | '$' |
| «7» | '{' |
| «8» | '[' |
| «9» | ']' |

Travaux:

| Clé | AltGr + Key, attendu: |
| ----- | ----------------------- |
| «0» | '}' |
| '´' | '|' |
| '<' | '\' |
| '¨' | '~' |
| 'e' | '€' |

Remarque: «´», «¨» sont des types de clé morte.

Système: Windows 10 64bit Home 1903 Build 10.0.18362.267
Terminal Windows: Aperçu v0.3.2142.0 - Version Store
Disposition du clavier: danois.

@MasMedIm , @ sba923 , @lhecker - Vos versions Windows Home sont-elles comme les miennes?
Edit: Oubliez ma question. J'étais sur le point de commencer une chasse à l'oie sauvage là-bas ;-), mais @lhecker semble avoir résolu la régression!

@ DHowett-MSFT @ henrik-jensen et. al .: J'ai trouvé la cause de la régression. ¯ \ _ (ツ) _ / ¯
... et cela fait de nous tous ici un groupe de crétins pour l'avoir remarqué plus tôt. 😂

Le nouveau profiles.json contient des raccourcis du genre Ctrl+Alt+[0-9] pour passer rapidement à l'onglet 1-10.
Si vous supprimez ces raccourcis de votre fichier de paramètres ( Ctrl , ), la régression est corrigée.
Certaines combinaisons comme AltGr E pour € n'ont malheureusement jamais encore fonctionné et quelqu'un doit prendre le temps nécessaire pour résoudre ce problème.

En raison du fonctionnement des anciennes API Windows, il sera difficile de différencier de manière fiable les raccourcis Ctrl Alt et les pressions sur les touches AltGr , mais je vais vérifier si la situation peut être améliorée d'une manière ou d'une autre.

@lhecker 🥇 👍
Confirmé. Jubii

Certaines combinaisons comme AltGr E pour € n'ont malheureusement jamais encore fonctionné et quelqu'un doit prendre le temps nécessaire pour résoudre ce problème.

AltGr E -> '€' fonctionne sur ma disposition de clavier danois. Je vais essayer d'ajouter une mise en page allemande sur la mienne pour voir si elle est reproductible sur ma configuration.

Pourquoi ne pas mordre la balle? Conserver l'ancien CMD.EXE pour les applications héritées (DOS) et concevoir le nouveau terminal uniquement pour l'avenir? Non pas que la rétrocompatibilité ne soit pas géniale - mais parfois vous devez simplement couper les liens ...

@lhecker 🥇 👍
Confirmé. Jubii

Certaines combinaisons comme AltGr E pour € n'ont malheureusement jamais encore fonctionné et quelqu'un doit prendre le temps nécessaire pour résoudre ce problème.

AltGr E -> '€' fonctionne sur ma disposition de clavier danois. Je vais essayer d'ajouter une mise en page allemande sur la mienne pour voir si elle est reproductible sur ma configuration.

Installé allemand ~ Kezboard ~ ups, clavier :-) *, et AltGr E -> '€' fonctionne dans cette configuration.

Edit: * «z» / «y» sont échangés sur les claviers allemand / danois.

Le nouveau profiles.json contient des raccourcis du genre Ctrl+Alt+[0-9] pour passer rapidement à l'onglet 1-10.

Pour une raison quelconque, ces raccourcis sont alt + [0-9] dans mon fichier de paramètres et je n'ai donc pas eu le problème

Quelques questions me viennent maintenant à l'esprit:

• @lhecker Peut-être @lhecker a fait une pull request # 2235
• Je me demande où la valeur par défaut ~ settings.json ~ profiles.json est générée. Ce n'est pas une ressource, donc je suppose que c'est codé en dur quelque part? Edit: trouvé CascadiaSettings.cpp L369
• Quels raccourcis alternatifs devraient être choisis à la place. Peut-être que ceux que @saadanerdetbare a dans son ~ settings.json ~ profiles.json (Étaient-ils la valeur par défaut dans la version antérieure à la 0.3.2142.0? Edit: Cela semble être le cas - # 2014)

@lhecker @ henrik-jensen qui aurait du sens. J'ai installé à partir du magasin juste après sa publication et j'ai apporté des modifications à profiles.json Donc, si la mise à jour n'écrasait pas le fichier parce qu'il était personnalisé et non par défaut, je n'ai pas obtenu les raccourcis Ctrl + Alt

@ DHowett-MSFT @ henrik-jensen et. al .: J'ai trouvé la cause de la régression. ¯_ (ツ) _ / ¯
... et cela fait de nous tous ici un groupe de crétins pour l'avoir remarqué plus tôt. 😂

Le nouveau profiles.json contient des raccourcis du genre Ctrl+Alt+[0-9] pour passer rapidement à l'onglet 1-10.
Si vous supprimez ces raccourcis de votre fichier de paramètres (Ctrl,), la régression est corrigée.
Certaines combinaisons comme AltGrE pour € n'ont malheureusement jamais encore fonctionné et quelqu'un doit prendre le temps nécessaire pour résoudre ce problème.

En raison du fonctionnement des anciennes API Windows, il sera difficile de faire la différence de manière fiable entre les raccourcis CtrlAlt et les pressions sur les touches AltGr réelles, mais je vais vérifier si la situation peut être améliorée d'une manière ou d'une autre.

Ty pour la réponse, en effet c'était les paramètres Ctrl + Alt + [0-9]

@saadanerdetbare , Ouais, il a été changé de vos paramètres aux nouveaux ici # 2014 par @ zadjii-msft

Je confirme que les nouveaux raccourcis cassent AltGr ( ~#{[|`\^@]} ) sur mon clavier français.

La raison pour laquelle certains d'entre nous n'ont pas vu la régression est liée au fait que la mise à niveau 0.3 ne remplace pas un profiles.json existant, ce qui est documenté dans Windows Terminal Preview v0.3 Release :

Remarque: si vous avez déjà installé le terminal avant cette version, ces raccourcis clavier n'apparaîtront par défaut qu'une fois que vous aurez supprimé votre profiles.json et lui permettre de se régénérer. Vous pouvez enregistrer vos profils originaux.json ailleurs et copier vos personnalisations ou simplement ajouter ces raccourcis clavier manuellement. Nous sommes conscients que ce n’est pas une expérience idéale et nous travaillons à l’améliorer.

On peut utiliser ctrl + alt + shift + _digit_, bien que ce ne soit pas très facile à saisir ...

@ henrik-jensen J'ai ouvert le # 2235.

@thorsig On vous a déjà expliqué l'état des choses dans le paysage des API Windows.
Surtout étant donné que, par exemple, bash sous Linux (comme la plupart des shells que vous voudrez peut-être utiliser sous Windows à l'avenir) _ne_ ne reçoit pas_ de codes de touches bruts, mais plutôt du texte régulier imprégné de séquences d'échappement. Les séquences d'échappement que votre terminal doit générer à partir des événements de clavier. Votre shell Linux _ ne gère pas_ les codes clés bruts. Votre terminal le fait.
Avant de continuer, vous devez d'abord comprendre comment fonctionnent xterm et vt100 (et versions ultérieures).
Et btw: les codes de touches sous Linux ne sont également qu'une abstraction virtuelle (! = Brute) sur les scancodes de votre clavier - voir keymaps.5 . La seule différence est que sur Windows, il a été décidé il y a longtemps que Ctrl + Alt est le même que AltGr, car certains claviers manquaient de touches AltGr, mais on voulait toujours pouvoir appuyer sur AltGr d'une manière ou d'une autre. Les gens qui ont décidé que c'était peut-être plus de 60 ans de nos jours. Changer cela n'est pas trivial et n'a qu'un avantage insignifiant (puisque vous pouvez déjà détecter les pressions sur les touches AltGr dans la pratique).

Je confirme que les nouveaux raccourcis cassent AltGr ( ~#{[|`\^@]} ) sur mon clavier français.

La raison pour laquelle certains d'entre nous n'ont pas vu la régression est liée au fait que la mise à niveau 0.3 ne remplace pas un profiles.json existant, ce qui est documenté dans Windows Terminal Preview v0.3 Release :

Remarque: si vous avez déjà installé le terminal avant cette version, ces raccourcis clavier n'apparaîtront par défaut qu'une fois que vous aurez supprimé votre profiles.json et lui permettre de se régénérer. Vous pouvez enregistrer vos profils originaux.json ailleurs et copier vos personnalisations ou simplement ajouter ces raccourcis clavier manuellement. Nous sommes conscients que ce n’est pas une expérience idéale et nous travaillons à l’améliorer.

On peut utiliser ctrl + alt + shift + _digit_, bien que ce ne soit pas très facile à saisir ...

Il est plus facile d'utiliser alt + _digit_ et il est similaire aux raccourcis de gnome-terminal.
Cela fonctionne sur mon clavier français.

Si vous utilisez Alt + chiffre , sachez que vous ne pourrez pas envoyer ces clés dans une application console.

: tada: Ce problème a été résolu dans # 2235, qui a maintenant été publié avec succès sous le nom Windows Terminal Preview v0.3.2171.0 .: tada:

Liens utiles:

• Notes de version
• Téléchargement du magasin

AltGr ( ~#{[|`\^@]}¤€ ) fonctionne bien ici avec un clavier français, Windows 10 version 1903 build 18362.267, Windows Terminal Preview 0.3. 2171 .0, et les raccourcis de changement d'onglet définis sur Ctrl+Alt+digit .

Bon travail!

Merçi pour la confirmation!

Vous êtes les bienvenus!

0.3.2171.0 correctif confirmé pour mon système - Clavier danois Win10 Home 1903 build 10.0.18362.267.
J'ai supprimé mon profiles.json pour obtenir les paramètres par défaut et maintenant AltGr fonctionne également pour une nouvelle installation (je suppose).
Excellent travail @lhecker et toutes les autres personnes impliquées.

Salut, je pense que j'ai ce problème sur la version 0.7.

Je ne peux pas non plus saisir la touche barre oblique de mon clavier en utilisant le pavé numérique ou AltGr + Q (clavier brésilien ABTN2 d'un ordinateur portable Samsung qui n'a pas la touche point d'interrogation / barre oblique).

Edit: je ne peux pas entrer de touche AltGr.

Après avoir supprimé une ancienne version de PSReadline, tout fonctionne maintenant.

FWIW, j'ai écrit les scripts PowerShell attachés pour vérifier quelles versions de PSReadline sont sur mon système / laquelle est active.

CheckPSReadLineStatus.zip

HTH

Pour résoudre le même problème que celui signalé par beppler, procédez comme suit:

Après avoir supprimé une ancienne version de PSReadline, tout fonctionne maintenant.

À partir d'une session PowerShell élevée, faites:

Install-Module -Name PowerShellGet -Force
Exit

À partir d'une session cmd élevée, procédez comme suit:
powershell -noprofile -command "Install-Module PSReadLine -Force -SkipPublisherCheck -AllowPrerelease"

Quel est le statut de ce problème?
Parce qu'en regardant les problèmes liés, cela semble résolu, mais cela ne fonctionne toujours pas pour moi. Pour imprimer le caractère ~ sur une disposition de clavier italien, j'ai l'habitude de faire Alt + 126 mais cela a un comportement différent selon le type de terminal, mais dans aucun d'entre eux, je ne peux obtenir le caractère ~ imprimé, tout en faisant directement dans le shell sous-jacent (git / cmd / powershell / wsl non intégré dans le terminal Windows) fonctionne comme prévu

Cela m'arrive avec la dernière version du terminal Windows, au moment de l'écriture est:

Windows Terminal (Preview)
Version: 0.8.10091.0)

@ilmax J'ai cassé l'entrée Alt + Numpad dans # 3117. Maintenant que # 3117 avait été fusionné et que le problème associé avait été résolu, nous pourrions travailler à réintroduire l'entrée du pavé numérique dans la base de code.
J'en ferais cependant un comportement facultatif et configurable, car je suis assez certain que la plupart des utilisateurs potentiels de l'application Terminal n'en bénéficieront plus. L'application devrait donc envoyer par défaut toutes les entrées clavier possibles au shell afin que vous puissiez configurer des combinaisons de touches vim, etc. plus avancées.
La mise en œuvre devrait être un peu plus facile dès que # 4192 sera fusionné. Vous devrez ajouter la logique supplémentaire ici et vérifier si la touche Alt (et uniquement la touche Alt) est maintenue dans states , tandis que la touche v provient du pavé numérique par opposition aux touches numériques régulières . N'hésitez pas à soumettre un PR à tout moment! 🙂

@lhecker merci pour la réponse rapide, je voulais juste connaître l'état de cela parce que chaque problème que j'ai trouvé était fermé mais le problème est toujours là.
Je ne suis pas sûr de trouver un PR à ce sujet, je n'ai jamais regardé le code avant 😄 donc je ne sais vraiment pas par où commencer, malgré votre suggestion.

Je voulais juste savoir comment réparer mon flux de travail pour git rebase -i car maintenant je dois ouvrir quelque chose comme notepad ++, taper le caractère ~, le copier et le coller dans le terminal.

Juste pour que je comprends: vous êtes sur un fil sur AltGr avec une question sur _alt + séquences de pavé numérique_? C'est peut-être pourquoi tous les threads que vous trouvez sont fermés: le problème AltGr est résolu.

Je pense que nous avons un problème distinct de suivi des problèmes d'entrée alt + pavé numérique.

Oui, vous avez raison, désolé pour la confusion. Je pense que le # 657 est peut-être le bon