Update: Dasselbe passiert mit allen Ziffern, wenn es mit Alt Gr kombiniert wird.

Weißt du, das liegt wahrscheinlich an mir. Wir bekommen vkey wahrscheinlich nicht richtig für AltGR-Combos irgendwo in TermControl.cpp, wenn wir das KeyDown-Ereignis bekommen.

Ein bisschen unabhängig, aber welche Software haben Sie verwendet, um eine Aufnahme mit den Tasten zu erhalten, die Sie im gif @patriksvensson gedrückt

@watermelonpizza Ich habe Carnac verwendet , um die Tastendrücke anzuzeigen , und

Oh Carnac, super danke! Ich werde das zu meiner Liste der Leckereien hinzufügen :)

Ich denke, das ist ein Duplikat von # 487.

Hoppla, es sieht so aus, als ob die linke Hand nicht weiß, was die rechte Hand tut, und ich habe gerade einen kreisförmigen doppelten Link erstellt.

Kann dieses Problem unter Windows Version 10.0.18362.30 mit ungarischem Tastaturlayout bestätigen. Das Verhalten ist unterschiedlich, je nachdem, welche Konsole ich verwende:

• cmd: Es wird nur das Zeichen geschrieben, jedoch in Großbuchstaben
• Powershell: macht überhaupt nichts
• git bash: schreibt nichts aus, spielt aber den Standard-Piepton

@ zadjii-msft Ich habe Ihren (?) AltGr-bezogenen Kommentar in terminalInput.cpp .
Auf meiner deutschen Tastatur ist der Steuertastenstatus LEFT_CTRL_PRESSED | LEFT_ALT_PRESSED anstelle des scheinbar erwarteten LEFT_CTRL_PRESSED | RIGHT_ALT_PRESSED .
Außerdem ist die gedrückte virtuelle Taste zB "Q" anstelle eines bereits transformierten Unicode-Zeichens.

Also habe ich ersetzt ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
mit...

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

...und es funktioniert! Zur Zeit. 😅 Das Handling wird an WM_CHAR / _CharacterHandler delegiert, das laut Google für das AltGr-Handling robuster ist. (?) (Ich bin noch nicht sehr vertraut mit Windows-Programmierung.)
Was denkst du über dies? Soll ich eine PR einreichen?

@lhecker Super ! Nun ist dies tatsächlich verwendbar 🎉

@lhecker Ja, bitte PR einreichen. Auf deutschen Tastaturen kann ich die Pipe momentan nicht eingeben, was die Verwendung des Terminals erschwert.

Ich habe das Gefühl, dass meine Änderung falsch ist. Es muss einen Grund geben, warum nicht alle Zeichen von WM_CHAR oder?
Aus diesem Grund möchte ich zuerst auf das Feedback von @ zadjii-msft oder @ DHowett-MSFT warten. Meiner Ansicht nach? 😅

Die eigentliche Ursache ist in Terminal.cpp

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

Sie können sehen, dass RIGHT_ALT_PRESSED hier nie korrekt erkannt wird, was dazu führt, dass keyEvent.IsAltGrPressed in TerminalInput :: HandleKey false zurückgibt.

Übrigens wird der Modifikatorstatus von _GetPressedModifierKeys () in TermControl :: _ KeyDownHandler () erfasst. Anstelle eines booleschen Werts können Sie den Status der Modifikatoren direkt an SendKeyEvent übergeben und bestimmen, ob die Strg-Taste links / rechts, links / rechts alt, links / rechts später gedrückt wird.

In VirtualKey sind bereits folgende Definitionen definiert, die in TermControl :: _ GetPressedModifierKeys () verwendet werden können.

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

Ah schöner Fang @sagood!
Leider reicht es nicht aus, dieses Problem zu beheben, soweit ich sehen kann ...
TerminalInput::HandleKey geht anscheinend davon aus, dass das Betriebssystem beim Drücken von AltGr das UnicodeChar bereits auf den richtigen alternativen Wert vorübersetzt hat, was beispielsweise bei AltGr + Q (= @) auf einer deutschen Tastatur nicht der Fall ist.
Das heißt, die aktuelle Logik um IsAltGrPressed() ist bereits ein bisschen fehlerhaft.

@lhecker Ich habe versucht, stattdessen RIGHT_ALT_PRESSED zu verwenden, um DWORD-Modifikatoren zu initialisieren. Ich habe AltGr + '+' (= ~) getestet, es wird korrekt in der Konsole angezeigt.
AltGr + <(= |) funktioniert auch.

Aber AltGr + Q scheint in der Tat nicht zu funktionieren. seltsam.
AltGr + E (= €) funktioniert auch nicht.

Beim Einrichten eines neuen c # UWP habe ich festgestellt, dass die Tastenfolge bei Verwendung von AltGr wie folgt lautet:

Menu
Control
Q

(Nehmen Sie als Beispiel AltGr + Q)

Weiteres Debuggen zeigt, dass, wenn Sie das Programm zwingen, den ersten Bedingungszweig von TerminalInput :: HandleKey von terminalInput.cpp wie unten gezeigt auszuführen,

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 wird funktionieren.

Wie wäre es mit AltGr + ß für \ auf der deutschen Tastatur, dass man das gleiche Problem hat

Alle AltGr-Tastaturkombinationen sind von demselben Problem betroffen.

Irgendwelche Fortschritte in diesem Bereich? Ich war in der Lage , das Verhalten zu reproduzieren, aber ich bin nicht sicher, wie der AltGr Fall sollte eigentlich behandelt werden. Falls es hilft, hier sind einige Dinge, die ich mir angesehen habe:

• Ich habe überprüft, dass AltGr auf einer deutschen Tastatur tatsächlich in Left_CTRL && LEFT_ALT und auf CMD, PS und WSL getestet wurde
• Es scheint, dass der Fehler mit nicht bestandenen Tests zusammenhängt. Die folgenden Tests schlagen für mich fehl, wenn ich zu einer deutschen Tastatur wechsle, aber die englische Tastatur weitergebe:
  
  
  
  • InputEngingeTest:C0
  
  
  • InputTest::TerminalInputModifierKeyTests#metadataSet3 bis einschließlich set10
  
  

@lhecker Aus Neugier habe ich Ihre erste Idee, isAltGrPressed() durch isAltPressed() && isCtrlPressed() ersetzen, angewendet und überprüft, ob:

• funktioniert für CMD einschließlich @ und €, jedoch nicht in PS oder WSL
• behebt die nicht bestandenen Tests nicht
• sondern bricht MouseInputTest::SgrModeTests#metadataSet20 für die englische Tastatur.

Obwohl ich nicht weit gekommen bin, um das Problem weiter einzugrenzen, dachte ich, dass die Informationen nützlich sein könnten.

Das ist sehr interessant @MattKuhr. @ und € funktionieren für mich sowohl in PowerShell als auch in WSL. 🤔
(Nur um 100% sicher zu sein - Dies ist mein Unterschied zum aktuellen Master 67f68eb.)

Es ist in der Tat, ich habe auf den aktuellen Master aktualisiert und ihn erneut getestet. Jetzt funktionieren die Sonderzeichen bis auf € in PS.

Ich bin nicht sicher, was das zuvor beobachtete Verhalten verursacht hat. Es wurden genau dieselben Codeänderungen verwendet. Ich fange an zu glauben, dass ich beim Testen möglicherweise etwas mit der Bereitstellung durcheinander gebracht habe, obwohl ich mehrere Tests durchgeführt habe, oder dass einige Windows-Updates, die in der Zwischenzeit installiert wurden, Auswirkungen hatten.

Dies ist eine Bildschirmaufnahme mit der deutschen Tastatur, die beim Testen auf dem aktuellen Master eingestellt wurde:

Ich habe es sowohl unter Debug als auch unter Release (x64) unter Win 10.0.18362.116 getestet. Ich habe auch versucht, die Systemsprache zu ändern, was keine Auswirkung hatte. Es scheint ein wenig seltsam, dass nur in diesem einen speziellen Fall der € nicht richtig übersetzt wird.

Angenommen, funktioniert es in PowerShell, wenn Sie zuerst Remove-Module PSReadline ? (Keine Sorge, es wirkt sich nur auf Ihre aktuelle Sitzung aus.) Wenn ja, haben wir einige Ideen!

@ DHowett-MSFT Ich habe es mit einem Build der gestrigen Master-Kaufabwicklung ohne Änderungen an einem deutschen Tastaturlayout in 18362.113 getestet (Spracheinstellung ist Englisch).

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

Bei normalen Zeichen funktioniert Alt Gr wie Shift. Jedes andere Zeichen bleibt ohne Modifikator auf dem Wert.

@ DHowett-MSFT Es tut eigentlich 😃

Die anderen Tasten funktionieren weiter. Früher wurde die winzige 3 als normale 3 geschrieben, jetzt wird sie korrekt angezeigt, wie Sie im folgenden Screenshot sehen können.

Hallo,

Nur um dies zu verdeutlichen, wirkt sich dies auch auf das finnische QWERTZ-Layout aus, sodass alle AltGr-Kombinationen wie @, |, {}, [], ~, \ usw. unbrauchbar werden.

All dies scheint mit dem Patch von @lhecker in WSL, cmd und Powershell gut zu funktionieren. Danke @lhecker !

Hallo, es funktioniert auch für das französische Azerty-Tastaturlayout. Danke @lhecker

Probleme mit Alt Gr-Kombinationen, z. B. "Alt Gr + <" (Backslash, führt aber zu "<") auf einer schweizerdeutschen Tastatur.

Ich habe den Titel dieser Ausgabe aktualisiert, um Passanten klarer zu machen, was sie verfolgen.

@ zadjii-msft Ich habe Ihren (?) AltGr-bezogenen Kommentar in terminalInput.cpp gefunden.
Also habe ich ersetzt ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
mit...
if (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
falsch zurückgeben;
}}
...und es funktioniert! Zur Zeit. 😅

Durch diese Änderung bekomme ich auch ein verwendbares AltGr auf meiner französischen Tastatur. Bisher mit CMD, Windows PowerShell 5.1 und PowerShell Core 6.2.1 getestet (beide mit der inoffiziellen PSReadline 2.0.0beta4, die für die Arbeit mit VScode erforderlich ist)

Durch diese Änderung bekomme ich auch ein verwendbares AltGr auf meiner französischen Tastatur. Bisher mit CMD, Windows PowerShell 5.1 und PowerShell Core 6.2.1 getestet (beide mit der inoffiziellen PSReadline 2.0.0beta4, die für die Arbeit mit VScode erforderlich ist)

Ich habe meine PSReadline-Version überprüft und von 2.0.0 auf 2.0.0-beta4 aktualisiert. Das hat den Trick getan. Jetzt funktionieren € und ³ auch in PS korrekt, sowohl in 5.1 als auch in 6.2.1. 😄

Ich habe zwar einen anderen Fehler gefunden, der ebenfalls mit PSReadline zusammenhängt, aber nicht direkt mit AltGr oder dem Tastaturlayout. Wie Sie unten sehen können, wird im Terminal CTRL 2 in " und CTRL 7 (im GER-Layout in den USA CTRL / ) in ^_

Im ersten Fall reicht das Entfernen von PSReadline aus, im zweiten Fall nicht. Ich habe die andere Nummer und die speziellen Zeichenschlüssel ausprobiert, aber diese beiden waren die einzigen zwei Instanzen, die ich bisher finden konnte. Das Verhalten ist für 5.1 und 6.2.1 identisch. PSReadline ist 2.0.0beta4.

Sollten wir dafür eine separate Ausgabe eröffnen?

Ich sehe auch verwandte Probleme auf einer portugiesischen Tastatur (Portugal).
Erwartet: Alt Gr + 2/3/4/7/8/9/0 sollte @ £ § {[]} ausgeben, Alt Gr + e sollte € erhalten

Windows Terminal:
-PS Core: Alt Gr + Ziffer löst PSReadline DigitFunction aus, außer 7 Ausgängen ^ _
-PS Core: Alt Gr + € macht nichts
-Windows Powershell: Wie PS Core
-CMD: Alt Gr + Ziffer gibt die Ziffer aus, außer 7 Ausgänge ^ _
-CMD: Alt Gr + e gibt E aus

Eingebaute Konsole:
PS Core: Alt Gr + 2/3/4/7/8/9/0 Ausgabe @ £ § {[]}, Alt Gr + E macht nichts
Windows PowerShell: Wie PS Core
CMD - Alles funktioniert

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

Eine bewährte Problemumgehung, wenn die Tastenkombinationen "Alt Gr" nicht funktionieren, ist die Verwendung von Alt + NumPad-Code .

Das funktioniert aber auch nicht!

657 "Alt + Numpad funktioniert nicht"

Ich würde raten, dass jeder, der sich mit diesem Thema befasst, auch dieses eng verwandte Thema anspricht.

Ich kann dies auch für die isländische Tastatur überprüfen. Wir verwenden AltGr, um diese zu schreiben:
@ | € {[]} \ µ ~ `^

Nur eine Randnotiz: Dieses Problem tritt bei nahezu allen Microsoft-Befehlszeilentechnologien auf. Es ist bereits in OpenSSH aufgetreten , ein ähnliches Problem ist in

Jedes Mal, wenn ich etwas über die Befehlszeile ausprobiere, treten immer Eingabeprobleme auf. Ich kann PowerShell in Remotesitzungen immer noch nicht verwenden, da Home-End nicht funktioniert und SSH immer noch nicht funktioniert.

Irgendwie ist dieses Terminal-SSH-PSReadline-Dreieck verflucht.

Hier verwende ich das PT-BR-Tastaturlayout.

Um / ich Alt Gr + Q

Bei Verwendung in Terminal funktioniert dies wie ein Rückgängig-Befehl. Es wird nur mein letzter Befehl / Buchstabe / Wort erneut eingegeben

@ MathiasMagnus

wo keine der AltGr-Kombinationen nicht funktioniert.

Sie wollen damit sagen, dass keine der AltGr-Kombinationen funktioniert?

Angenommen, funktioniert es in PowerShell, wenn Sie zuerst Remove-Module PSReadline ? (Keine Sorge, es wirkt sich nur auf Ihre aktuelle Sitzung aus.) Wenn ja, haben wir einige Ideen!

Funktioniert bei mir nicht (französisches AZERTY-Layout)

also ..... irgendwelche neuen ideen? weil das fix ...

`` `c ++
if (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
falsch zurückgeben;
}}
...

hat bei mir nicht funktioniert <. <

Bearbeiten:

Ist es nicht klüger, die auf dem Computer definierte Haupttastatursprache zu erkennen und dann das Rebind-Zeug @microsoft auszuführen ?

@ Hedrauta komisch, dass die Codeänderung bei dir nicht funktioniert. Welches Tastaturlayout verwenden Sie? Was macht Ctrl+Alt+xxx für Sie in einer normalen CMD für Werte von xxx , die in Kombination mit AltGr verwendet werden? Soweit ich mich erinnern kann, sollte Ctrl+Alt immer AltGr ...

Um einige Testdaten zu sammeln: Für mich scheint der Patch von @lhecker gut zu funktionieren. Dies ist auf einem deutschen Tastaturlayout:

Terminal | Alt Gr + ß? \ | Strg + Alt + ß? \
- | - | -
Vermächtnis cmd.exe | \ | \
Vermächtnis pwsh.exe | \ | \
Windows Terminal, master , cmd.exe | ß | ß
Windows Terminal, master , pwsh.exe | _ (nichts) _ | _(nichts)_
Windows Terminal, master + Patch von @lhecker , cmd.exe | \ | \
Windows Terminal, master + Patch von @lhecker , pwsh.exe | \ | \

Gleiches Ergebnis wie unter https://github.com/microsoft/terminal/issues/521#issuecomment -501148984
mit dem Patch von @lhecker

Aber in pwsh funktioniert das € - Zeichen immer noch nicht im deutschen Layout.

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 komisch, dass die Codeänderung bei dir nicht funktioniert. Welches Tastaturlayout verwenden Sie? Was macht Ctrl+Alt+xxx für Sie in einer normalen CMD für Werte von xxx , die in Kombination mit AltGr verwendet werden? Soweit ich mich erinnern kann, sollte Ctrl+Alt immer AltGr ...

Es hat mir auch nicht geholfen ...
Ich habe sogar versucht, meine eigene Problemumgehung basierend auf diesem Code zu erstellen, aber bisher kein Glück ...

Ich verwende das PT-BR-Tastaturlayout und versuche die folgende Kombination:

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

Bei Verwendung des Windows-Terminals
WSL: AltGr + Q = funktioniert wie ein Rückgängig-Befehl und schreibt meine zuletzt eingegebenen Zeichen neu.
Powershell, CMD: AltGr + Q = erzeugt dieses seltsame Zeichen druckt wie ^_

Bearbeiten:
Zur Visualisierung:

Die richtige Eingabe sollte sein
AltGr + Q = /
AltGr + W = ?
AltGr + [ = ª
AltGr + ] = º

@ renatop7 was bekommst du mit CtrlAlt anstelle von AltGr?

@ renatop7 was bekommst du mit CtrlAlt anstelle von AltGr?

Das gleiche Ergebnis

Und außerhalb des Terminals, dh in Standard-CMD oder Windows Powershell oder Powershell Core? Verhält sich CtrlAlt immer wie AltGr?

Und außerhalb des Terminals, dh in Standard-CMD oder Windows Powershell oder Powershell Core? Verhält sich CtrlAlt immer wie AltGr?

Ja, außerhalb des Terminals funktioniert es perfekt.
Bei Verwendung von AltGr oder Strg + Alt erhalte ich das erwartete Ergebnis.

vor 15 Minuten abgeholt: überhaupt nicht arbeiten
Arbeiten Microsoft überhaupt an einer Lösung für dieses Problem?

@ Hedrauta komisch, dass die Codeänderung bei dir nicht funktioniert. Welches Tastaturlayout verwenden Sie? Was macht Ctrl+Alt+xxx für Sie in einer normalen CMD für Werte von xxx , die in Kombination mit AltGr verwendet werden? Soweit ich mich erinnern kann, sollte Ctrl+Alt immer AltGr ...

Ähm, Standard Deutsch?. Hier ein Bildschirm, wie er aussieht: https://i.imgur.com/mvgHkxi.png
Ich werde versuchen, den Schlüssel durch ein Makro einzugeben .... Testen

Es ist so, als ob mein linker Alt Shift ist, nicht Alt ...
versuchte Ergebnis
Strg + Q ^ Q.
STRG + Alt + QQ
nur Q q
Alt + QQ

Ich werde versuchen, es zu geben und dann den Kommentar zu aktualisieren
Bearbeiten: Beim Versuch, es zu geben, wurde mir klar, dass meine Alt-Taste falsch erkannt wird ... weiß jemand, wo die virtuellen Schlüssel definiert sind? werde es auch untersuchen;) aber ich bin nicht so erfahren in c ++ oder .... irgendeiner Codierung;)

Nur für mich als CPP-Noob habe ich mehrere Dateien überprüft und die gefunden
C: \ Programme (x86) \ Windows Kits \ 10 \ Include \ 10.0.17763.0 \ um \ WinUser.h
Also ... für deutsche Layouts existiert das VK_Menu nicht, oder? Wir besitzen nur die VK_LMENU, oder?
Ich werde einige Änderungen versuchen und einige Tests durchführen ... werde die Ergebnisse später bearbeiten
Edit 1: Das Erstellen dauert lange, so wie ich meine gesamten Systeme neu aufbaue
Edit 2: Nach dem Erstellen des Ganzen funktioniert es nicht ... aber ich habe festgestellt, dass VK_RMENU AltGr ist, während VK_LMENU die Taste ist, die gedrückt werden soll, um unser @ oder \ zu erhalten
VK_MENU sieht aber auch gut aus, kann aber falsch zugeordnet sein
Das verwirrt mich irgendwie, ich werde dies nach einem sauberen Abruf, Wiederaufbau und einem Nickerchen überprüfen

Für das deutsche Tastaturlayout ist es sogar noch schlimmer, weil Alt Gr + Q das nur @ ausgeben sollte, die aktuelle Zeileneingabe löscht.
Das passiert mit wsl nicht und ich sehe es auch nicht für WT konfiguriert. Wie passiert das?

Immer noch ein Problem:
Tastatur: Belgisch (Punkt) AZERTY, funktioniert in normaler Schale
Winver: 18362.175
Terminalversion: 0.2.1715.0

_Ich möchte alle bitten, nicht zu kommentieren, dass sie sich auch mit diesem Problem befassen._

Inzwischen sollte allen klar sein, dass dieses Problem eine große Anzahl von Tastenkombinationen betrifft und bei einer ebenso großen Anzahl von Sprachen, Windows-Versionen, Tastaturen usw. zu einer ebenso großen Anzahl unerwarteter Nebenwirkungen führen kann.
Mehr als die Hälfte der Kommentare hat einen # metoo-Stil, was zur Behebung dieses Problems überhaupt nicht beiträgt
macht nur hilfreiche Kommentare weniger sichtbar .
Was tatsächlich fehlt und eine große Hilfe wäre, ist, dass ein erfahrener Windows-Entwickler dieses Problem angeht und eine PR einreicht.

In der Zwischenzeit kann jeder, der dieses Projekt kompilieren kann, diesen Code ersetzen: https://github.com/microsoft/terminal/blob/ce4c6d6124c258c676b4eeac61a709c1fb3da459/src/terminal/input/terminalInput.cpp#L392 -L

mit diesem experimentellen Fix von mir:

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

Dies sollte die meisten Tastenkombinationen für die meisten Tastatursprachen korrigieren, einschließlich z. B. Zeichen wie @{}[] auf einer deutschen (oder ähnlichen) Tastatur.

PS: Ich bin in keiner Weise oder Form mit Microsoft verbunden und schreibe dies, weil ich diese "#metoo" -Kommentare persönlich als zu laut / unproduktiv betrachte. 🙂
PPS: Ich bin sicher, einige fragen sich, warum ich selbst keine PR einreiche. Um mich selbst zu zitieren : "Ich habe das Gefühl, dass meine Änderung falsch ist. Es muss einen Grund geben, warum nicht alle Zeichen von WM_CHAR oder?" Das heißt, ich weiß nicht genau, was die Nachteile des obigen Fixes sind und wie man es richtig macht.

PPS: Ich bin sicher, einige fragen sich, warum ich selbst keine PR einreiche. Um mich selbst zu zitieren: "Ich habe das Gefühl, dass meine Änderung falsch ist. Es muss einen Grund geben, warum nicht alle Zeichen von WM_CHAR behandelt werden, oder?" Das heißt, ich weiß nicht genau, was die Nachteile des obigen Fixes sind und wie man es richtig macht.

Eine Möglichkeit, dies zu wissen, besteht darin, eine PR einzureichen und sich vom Team korrigieren zu lassen. Es ist ein bisschen übertrieben, aber ich denke, es würde die Dinge schneller bewegen.

@ NATOBoram 😤👉 # 1436

Beachten Sie, dass bei Verwendung der Beispielanwendungen, z. B. VtPipeTerm, die Alt-Gr-Taste dort funktioniert.

@HBelusca VtPipeTerm basiert nicht auf dem neuen UWP-Terminal und hat daher dieses Problem nicht.
Sie können # 1436 lesen, um eine mögliche Erklärung für das zugrunde liegende Problem zu erhalten.

@lhecker Es basiert nicht auf Cascadia, verwendet jedoch dieselbe zugrunde liegende Pseudoconsole-Implementierung.

Danke @HBelusca

Spezialschlüssel funktionieren seit Jahren in Terminals und Windows-Apps. Warum haben wir dieses Problem jetzt im Jahr 2019? Haben Sie das Eingabesystem für das Terminalprogramm komplett neu implementiert? Ich hoffe, dass es notwendig war, dies zu tun und die vor Jahren behobenen Fehler erneut einzuführen: s. Dieses Problem war unter Linux aufgrund von Codepages, Sprach-Tastaturzuordnungen und Windows-spezifischen Tasten typisch. Dieser kritische Fehler tritt jedoch in der Vorschau-Version der Anwendung auf, die im Store verfügbar ist und überall veröffentlicht wird

@ifilgud Es ist eine Preview - Version verfügbar im Speicher für die Vorschau Gründe. Dieses Problem wurde getestet und es gibt auch eine eingereichte PR dafür, sodass Sie dieses Problem nicht kommentieren müssen, nur um sich zu beschweren.

@patriksvensson Ich weiß, dass ich mich hauptsächlich beschwert habe und das ist nicht "höflich", sondern fragt auch nach einem technischen Grund, um den Grund eines solchen Fehlers zu erklären. Ich hatte erwartet, dass einige kleinere Fehler in einer fast fertigen Version (Vorschau) behoben werden könnten, aber keine, die in einer Weiterentwicklung eines Terminals nicht hätte existieren dürfen, es sei denn, sie wurden von Grund auf neu geschrieben und nur in Englisch getestet (ich denke, das ist der Grund dafür in der ersten Alpha-Version nicht erkennen). Ich öffnete das Terminal und versuchte, "cd \" als zweiten Befehl zu schreiben (der erste war "dir"), und es funktionierte einfach nicht. Als Softwareentwickler hat mich das sehr beeindruckt.

@lhecker so weit, so gut, nachdem Sie Ihren experimentellen Fix

Vielen Dank für alle, die darauf hingewiesen und es bereits behoben haben. 🌷

Wie häufig wird die MS Store App aktualisiert?
Wann können wir also damit rechnen, dass in der Store-App Probleme behoben werden?

Würde gerne mit dem Terminal arbeiten, aber mit deutscher Tastatur kann man ohne altgr nicht einmal { } schreiben. 😅

Ich habe das gleiche Problem auch für das norwegische Bokmål-Tastaturlayout (nb-NO). Kann nicht [] oder {} oder $ erstellen. PowerShell ist ohne diese grundsätzlich kaputt.
Verwenden von UWP / Microsoft Store Version 0.2.1715.0 unter Windows 10 1903 18362.175.

hu_HU-Layout über AltGr: \ | & @ $ ; # <> {} [] Ich meine, wie oft öffne ich Klammern, spitze oder eckige Klammern, Backslash, Pipe, Dollarzeichen, Raute, "at", "und", Semikolon ... oh Warten Sie, jede Zeile? :) :)

_Ich möchte alle bitten, nicht zu kommentieren, dass sie sich auch mit diesem Problem befassen._

Inzwischen sollte allen klar sein, dass dieses Problem eine große Anzahl von Tastenkombinationen betrifft und bei einer ebenso großen Anzahl von Sprachen, Windows-Versionen, Tastaturen usw. zu einer ebenso großen Anzahl unerwarteter Nebenwirkungen führen kann.
Mehr als die Hälfte der Kommentare hat einen # metoo-Stil, was zur Behebung dieses Problems überhaupt nicht beiträgt
macht nur hilfreiche Kommentare weniger sichtbar.

Update: Dasselbe passiert mit allen Ziffern, wenn es mit Alt Gr kombiniert wird.

Wie hast du diese GIF-Aufnahme gemacht?

@ Karl-WE Schau weiter unten im Thread.

@ DHowett-MSFT Könnte eine gute Idee sein, diesen Thread mit einer Nachricht unten zu sperren

Während das Terminal für Powershell sehr unbrauchbar ist, während dieses Problem besteht
Ich möchte eine Problemumgehung für Windows 10 1903 für diejenigen aufrufen, die nicht verzichten können, bis sie behoben sind.

Problemumgehung:
Verwenden Sie die Windows-Taste +.
Gehen Sie zur Registerkarte Sonderzeichen und wählen Sie Ihren Charakter aus
Wechseln Sie zu Terminal und fügen Sie das Zeichen ein

Wenn Sie es entsperrt lassen, können Benutzer jeden einzelnen Schlüssel, der nicht funktioniert, melden, sodass sie keine einzelnen Probleme mehr über jeden einzelnen Schlüssel einreichen, der nicht funktioniert. Ich bin zerrissen.

Es kann weitere Fälle geben, in denen Sonderzeichen nicht wie erwartet angezeigt werden. Wenn ich ein @ -Zeichen auf einer dänischen Tastatur erstellen möchte, gibt es drei Möglichkeiten: Alt Gr + 2, Linke Strg + Linke Alt + 2 oder Linke Alt + Numpad 64
Die 2 ersten Optionen geben das gemeldete Ergebnis OP an.
Die letzte Option in Powershell:
Onpres Left Alt + Numpad 64 digit-argument: 64
Onrelease Left Alt: 64 @ Zeichen
In cmd
Onpres Left Alt + Numpad 64: 64
Onrelease Left Alt: @ führt zu 64@
In wsl
Onpres Left Alt + Numpad 64: (arg: 64)
Onrelease Left Alt: 64 @ Zeichen

Guter Punkt @saadanerdetbare!

Ihr Alt + Numpad-Problem scheint darauf zurückzuführen zu sein, dass das neue Terminal (Cascadia) bei der Eingabe dieser Codes geeignete Escape-Codes an die Shell sendet. Aber gleichzeitig ein anderer Teil der Anwendung ist daher _zusätzlich_ diesen Fall bearbeitet, die Übersetzung der Alt + Numpad Code in einen geeigneten Charakter und Einfügen , dass in die Schale. Dies führt dazu, dass der lustige Nebeneffekt Ihres @ -Zeichens 64 Mal wiederholt wird (da die folgenden Bytes an die Shell gesendet wurden: \x1b6\x1b4@ ).

Sie können dies ausprobieren, indem Sie den folgenden zusätzlichen Code zwischen diesen beiden Zeilen einfügen:

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

Dies verhindert, dass Cascadia diese Escape-Codes in die Shell sendet. Danach erscheinen Ihre Zeichen (zB @) normal.
Alternativ können Sie diesen Codeblock für denselben Effekt entfernen.

~ @saadanerdetbare Es wäre super, wenn Sie ein separates Problem erstellen könnten, das Ihr Problem detailliert beschreibt, da dies ein Fehler ist, der nichts mit der AltGr-Funktionalität zu tun hat. 🙂 ~
14 # 1401
Hätte zuerst nach anderen Themen suchen sollen. 🤦‍♂️

PS: Ich muss allerdings sagen, dass es mich persönlich sehr stolz machen würde, wenn die Community bereit wäre, diese Dinge selbst zu debuggen, anstatt sich auf unbekannte andere zu verlassen. 🙈🙂

@saadanerdetbare warten bei der Einreichung einer neuen Ausgabe, die ist # 1401: smile:

Ich erlebe dies immer noch in der Vorschau-App. Ich habe eine belgische Tastatur, die nicht geschrieben werden kann

@solispauwels Sie müssen bis zur nächsten Version warten (oder den aktuellen Master-Zweig vorerst selbst erstellen).

Hallo, ich habe gerade dieses Commit auf einer deutschen Tastatur getestet und alles funktioniert außer altgr-E, das das € -Symbol drucken sollte. Um ehrlich zu sein, brauche ich das in einem Terminal nicht so oft, aber ich dachte, ich könnte es trotzdem erwähnen. Andere mögen altgr-m für µ-Arbeit.

Update: Ich denke, Sie können das ignorieren, das € -Symbol funktioniert auch nicht in einer Standard-Powershell, so dass es nicht die Schuld des Terminals zu sein scheint. Sollte dies früher überprüft haben.

Auf einer französischen Tastatur scheint hier alles zu funktionieren: AltGr+é"'(-è_çà)=$e ergibt das erwartete ~#{[|`\^@]}¤€

Ich benutze auch eine französische Tastatur (aber ich bin in Belgien) und habe Probleme mit der AltGr +Zeichen. | # {} @ funktioniert zum Beispiel nicht. Ich verwende die neueste Version aus dem Windows Store 0.2.1715.0 unter Windows 10 v1903.

@meuter Sie müssen bis zur nächsten Version warten (oder den aktuellen Master-Zweig vorerst selbst erstellen).

Das Update von # 1436 ist noch nicht in der im Microsoft Store verfügbaren Vorschau-Version enthalten

@antoineco @ sba923 danke, das habe ich mir gedacht. Ich habe gerade das Repo geklont. Sobald mein vs2017 mit dem Update fertig ist, werde ich es aus dem Quellcode neu erstellen :-)

Vielen Dank an alle, die so hart daran gearbeitet und unsere Posteingänge mit Berichten gefüllt haben. Vielen Dank an @lhecker für die Übermittlung eines

Wir haben es gerade im Laden eingereicht

Aus meiner Erfahrung mit dem Veröffentlichen von Apps im Windows Store sollte es also 3 Tage bis 3 Wochen dauern 😉

Wir haben es gerade im Laden eingereicht

Aus meiner Erfahrung mit dem Veröffentlichen von Apps im Windows Store sollte es also 3 Tage bis 3 Wochen dauern 😉

Weniger als 6 Stunden scheint es. 😋

Wie auch immer, auf meiner schwedischen Tastatur scheint jetzt alles in Ordnung zu sein. 👍

Funktioniert jetzt mit der deutschen Tastatur 👍

Es funktioniert mit Französisch Tastatur mit Version 0.2.1831.0! Vielen Dank

Es funktioniert mit Französisch Tastatur mit Version 0.2.1831.0! Vielen Dank

Bestätigt!

Gut gemacht!

@ DHowett-MSFT Die Version 0.2.1831.0 scheint dieses Update zu enthalten, aber nicht andere Fehlerkorrekturen wie Powerline-Schriftarten oder Keybings zum Kopieren / Einfügen. Ist dies normal?

Ich bestätige, dass Alt-Gr funktioniert, aber die Verwendung von Strg-Alt für den Zugriff auf dieselben Tastaturtasten funktioniert nicht zuverlässig (wenn überhaupt).

In Version 0.2.1831.0 funktionieren AltGr-Kombinationen jetzt mit der finnischen Tastatur.

@solispauwels Die einzigen Korrekturen in Version 0.2.1831.0 sind die in den Versionshinweisen genannten.

Bitte beachten Sie, dass bei vielen Betriebssystemen ab 1803 möglicherweise ein Fehler in der Windows Store-Version 11905.1001.4.0 auftritt
Der Store "stapelt" Apps zum Herunterladen (siehe Bild), lädt die Apps jedoch nicht herunter, selbst wenn der automatische Download aktiviert ist und das Netzwerk keine gemessene Verbindung ist.

Betroffene Benutzer müssen im Microsoft Store auf "Nach Updates suchen" klicken, um schließlich eine feste Store-App zu erhalten und alle ausstehenden App-Downloads zu starten.

Ich bestätige, dass dieses Problem mit der neuen Version von Terminal behoben werden kann. Danke vielmals.

Ich kann auch bestätigen, dass dies jetzt behoben ist. Möglicherweise möchten Sie das Problem beheben.

Es funktioniert mit Ausnahme der Euro-Taste, die AltGr + e ist, zumindest in der spanischen Tastatur. Die restlichen Kombinationen funktionieren ordnungsgemäß

Von @ifilgud

Es funktioniert mit Ausnahme der Euro-Taste, die AltGr + e ist, zumindest in der spanischen Tastatur. Die restlichen Kombinationen funktionieren ordnungsgemäß

Getestet unter Windows 10 1903 (18362.175) mit der neuesten Version am 08.07.2019 mit der AZERTY-Tastatur "Belgian (Period)".

Testergebnis:

• Alle auf meiner Tastatur verfügbaren Kombinationen, einschließlich des Währungssymbols Euro (€), funktionieren in 2 der 3 im Windows-Terminal standardmäßig konfigurierten Konsolen: PowerShell Core und 'cmd' (Windows-Eingabeaufforderung)
• Nur in "Windows PowerShell" funktioniert das Euro-Symbol (€) nicht
  
  
  
  • Allerdings funktioniert es nicht in der Powershell - Klassik - Konsole gestartet direkt von Windows - Start als auch
  
  

Imo ist dies ein neues Problem im Zusammenhang mit Windows PowerShell, nicht spezifisch für Windows Terminal, das diese Konsole hostet.

Ich bestätige die Beobachtung von

Hier auf 10 Windows - Build 18.362,175 läuft Windows Terminal Preview - Version 0.2.1831.0, mit einer Französisch - Tastatur, AltGr+E hat ergeben € in allen folgenden Schalen:

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

Kann jemand mit verbleibenden AltGr Problemen in PowerShell überprüfen, welche Version von PSReadLine sie ausführen?

$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 könntest du bitte versuchen:

1. PSReadLine deaktivieren
2. Ein Upgrade auf die neuesten beta4 finden Sie unter https://github.com/PowerShell/PSReadLine

• Windows 10 1903
• Windows Terminal 0.2.1831.0
• PowerShell v7 (einschließlich PSReadline 2.0.0-beta4)
• Deutsches QWERTZ-Tastaturlayout

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

Dies ist besonders frustrierend, da es einen weiteren Fehler im Zusammenhang mit mstsc , den Microsoft seit mindestens einem Jahrzehnt ignoriert, bei dem AltGr + Q funktioniert, wenn eine RDP-Sitzung geöffnet ist. In diesen Situationen funktioniert Ctrl + Alt + Q immer noch, so dass viele Leute es als Problemumgehung verwenden.

Was Microsoft tun SOLLTE, IST NICHT DEN KEYBOARD STREAM ZU BERÜHREN.

Die Shell (explorer.exe) sollte alle erforderlichen Tastendrücke abfangen und alles andere stromabwärts übergeben.
Terminal.exe sollte letztendlich NUR Alt-F4 abfangen - und vielleicht auch nicht das - explorer.exe sollte das wirklich abfangen und auf den aktiven Prozess anwenden.

Das bedeutet, dass Terminal.exe nur den Tastatur-Stream nehmen und an den aktiven untergeordneten Prozess weitergeben sollte. Nichts anderes.

CMD.exe [command.com] sollte wissen, wie man das fängt, was es braucht, und den Rest dann an seine eigenen Kinder weitergibt.

Die WSL sollte so viel Rohdaten wie möglich erhalten. NICHT mit AltGr umgehen. Strg-Alt und AltGr sind NICHT die gleichen Tastatursequenzen. Unter Linux gibt es Verknüpfungen mit Strg-Alt -..., die andere Ergebnisse als AltGr -... liefern.

Sie haben nur EINE Gelegenheit, es richtig zu machen. Die erste Gelegenheit seit fast 40 Jahren. Bitte verpassen Sie diese Gelegenheit nicht - Microsoft, ich sehe Sie an :)

@thorsig ah, wenn wir Sie nur gehabt hätten, als der Win32-Eingabestapel vor etwa vierzig Jahren erstellt wurde. Leider haben wir das nicht getan, daher gibt es zwei Hauptmethoden, um Tastatureingaben zu erhalten:

• als Zeichen, ohne Modifikatoren (daher können wir ALT nicht erkennen, um es über die Terminalleitungen zu senden) oder Tastendruckrichtung
• als Scan-Codes, die Modifikatoren und Richtungen haben, aber wirklich nur Darstellungen von physischen Schlüsselpositionen sind

Wenn Sie anfangen, unter die Betriebssystemebene zu schauen, sind die Scan-Codes der Modus "so rohe Eingabe wie möglich". Sie erfordern jedoch ein wenig Kochen, bevor sie an Anwendungen weitergegeben werden können, die eine Texteingabe erfordern. (Zum Hinzufügen bearbeiten :) Terminalanwendungen bevorzugen ihre Eingabe als Text. Wir können keine Scan-Codes über eine SSH-Verbindung senden! Selbst wenn wir könnten, müsste der Empfänger dann selbst das Tastaturlayout verstehen, um die Übersetzung durchzuführen. Wahrscheinlich haben kopflose Maschinen kein Tastaturlayout. (/bearbeiten)

Wenn es so einfach wäre, „den wörtlichen Charakter zu bekommen, den sie gedrückt haben, und ihn mitzuschicken“, müssen Sie darauf vertrauen, dass wir genau das tun würden. Wir entwickeln keine verrückten Lösungen, weil wir verrückte Leute sind! :Lächeln:

Nun, ich war in der Nähe, obwohl ich zu diesem Zeitpunkt vielleicht keine Ahnung hatte, wie ich mit dem Eingabestream umgehen sollte.

Linux arbeitet jedoch standardmäßig mit den unformatierten Schlüsselcodes, sodass dies kein Problem darstellt. Ihr Beispiel für eine SSH-Verbindung ist jedoch fehlerhaft, da SSH niemals direkt von der Terminalanwendung ausgeführt wird. Im Inneren befindet sich eine Shell (oder eine gesamte Betriebssystemabstraktion wie WSL), die dafür verantwortlich ist, was die Shell erreicht.

Wenn das, was Sie angeben, richtig wäre, müsste jede Anwendung, die jemals für Windows geschrieben wurde (auf dem Explorer ausgeführt), ihre eigene Tastaturhandhabung implementieren. Sie tun es nicht. Weil es vor- und nachgelagert erledigt wird.

Ich habe mir den Code angesehen und hatte meinen Anteil an "SMH". Könnte ich es besser machen? Wahrscheinlich zu gegebener Zeit. Kann ich es mir leisten, darüber zu meckern? Da ich keine Zeit habe, es selbst zu tun - wahrscheinlich nicht.

Ich fand es immer noch erwähnenswert, dass es so wie es ist überarbeitet wird und irgendwann (wahrscheinlich früher als später) Probleme stromabwärts verursachen wird.

Nun, ich war in der Nähe, obwohl ich zu diesem Zeitpunkt vielleicht keine Ahnung hatte, wie ich mit dem Eingabestream umgehen sollte.

Linux arbeitet jedoch standardmäßig mit den unformatierten Schlüsselcodes, sodass dies kein Problem darstellt. Ihr Beispiel für eine SSH-Verbindung ist jedoch fehlerhaft, da SSH niemals direkt von der Terminalanwendung ausgeführt wird. Im Inneren befindet sich eine Shell (oder eine gesamte Betriebssystemabstraktion wie WSL), die dafür verantwortlich ist, was die Shell erreicht.

WSL macht keine bestimmte Art von Übersetzung. conhost.exe oder Windows-Terminal (oder Gnome-Terminal, wenn Sie eine grafische App beispielsweise über XMing ausführen) führen die richtige Übersetzung durch, um sie an die Pty zu senden. Und selbst die Shell ... es ist nicht die Shell selbst, die den größten Teil der Arbeit erledigt. Es ist der Terminaltreiber und die App am Master-Ende (wiederum entweder conhost.exe, Windows-Terminal, möglicherweise Cygwin-Terminal, wenn Sie dazu neigen, und die Linux-Terminal-Apps).

Wenn das, was Sie angeben, richtig wäre, müsste jede Anwendung, die jemals für Windows geschrieben wurde (auf dem Explorer ausgeführt), ihre eigene Tastaturhandhabung implementieren. Sie tun es nicht. Weil es vor- und nachgelagert erledigt wird.

Die meisten Apps kümmern sich eigentlich nicht um rohe Tastatureingaben. Dies wird in einigen Win32-Bibliotheken auf eine Weise behandelt, die von Natur aus verlustbehaftet ist. Sie verwenden keine rohen Tastatureingaben direkt. Die meisten Apps kümmern sich nur um Charaktere, außer um Spiele, bei denen es möglicherweise genau um die Eingabe des physischen Layouts geht. So oder so funktioniert es gut.

Ich habe mir den Code angesehen und hatte meinen Anteil an "SMH". Könnte ich es besser machen? Wahrscheinlich zu gegebener Zeit. Kann ich es mir leisten, darüber zu meckern? Da ich keine Zeit habe, es selbst zu tun - wahrscheinlich nicht.

Ich fand es immer noch erwähnenswert, dass es so wie es ist überarbeitet wird und irgendwann (wahrscheinlich früher als später) Probleme stromabwärts verursachen wird.

Ich schlage vor, Sie schauen sich Gnome-Terminal an, das Linux-Analogon, und prüfen, ob es einfacher oder komplexer ist. Ich vermute, dass es komplexer ist, da X tatsächlich seltsamer ist als das GDI32 oder die jeweils verwendete Fenster-API.

Gibt es eine Regression von 0.2.1831.0 ?
Auf der dänischen Tastatur reagiert Windows Terminal Preview v0.3.2142.0 nicht auf AltGr.

Windows Terminal (Vorschau)
Version: 0.3.2142.0
Microsoft Windows 1903 [Version 10.0.18362.267]

Ich habe dänische Tastatur und v0.3.2142.0 Windows Build 10.0.18362.239 Es ist ein englisches Betriebssystem ohne Sprachpakete. Die Alt Gr-Sonderzeichen funktionieren hier, die Strg + Alt-Sequenz nicht

Ich habe dänische Tastatur und v0.3.2142.0 Windows Build 10.0.18362.239 Es ist ein englisches Betriebssystem ohne Sprachpakete. Die Alt Gr-Sonderzeichen funktionieren hier, die Strg + Alt-Sequenz nicht

Meine Betriebssysteme: Win10 Home 1903 Build 10.0.18362.267
Dänisches Betriebssystem mit zusätzlichem US-Sprachpaket, obwohl das dänische Sprachpaket Standard ist.
Hmm - Build 10.0.18362.267 vs 10.0.18362.239 - gibt es da einen Hinweis? !!!

Meine Betriebssysteme: Win10 Home 1903 Build 10.0.18362.267
Dänisches Betriebssystem mit zusätzlichem US-Sprachpaket, obwohl das dänische Sprachpaket Standard ist.
Hmm - Build 10.0.18362.267 vs 10.0.18362.239 - gibt es da einen Hinweis? !!!

So erhalten Sie alle Details:
ich bin on
Win 10 Enterprise en-US 1903 Build 18362.239
Dänische Tastatur, kein Sprachpaket

Ich habe gerade versucht, mich in einem Konto mit dem US-Sprachpaket als Standard anzumelden. Dort wurde ein Terminal installiert und auf die dänische Tastatur umgeschaltet, um festzustellen, ob das ausgewählte Sprachpaket Einfluss hatte, aber dort kein Glück.

Ich weiß nicht, ob dies ein Hinweis für Kenner sein könnte, aber vor dem Upgrade auf 1903 von 1809 zeigte die Bildschirmtastatur ( c:\windows\system32\osk.exe ) in allen Conhost-Apps, cmd.exe, ubuntu / wsl, dasselbe Verhalten und Powershell.exe (ignoriert AltGr), aber 1903 scheint dies behoben zu sein.

Ich kann bestätigen, dass einige AltGr- Sequenzen nicht funktionieren.
AltGr Q (= @ ) funktioniert für mich, während AltGr 8 (= [ ) dies nicht tut.

Ich habe die Store-Version v0.3.2142.0 lokal erstellt, um dieses Problem zu beheben. Da ich nicht herausfinden konnte, wie der AzureConnector erstellt wird, musste ich ihn jedoch ausschließen: https://gist.github.com/lhecker/320662cb3fda70af1ca58eabf9f2579a
👉 Es stellt sich heraus, dass meine lokal erstellte Version 0.3.2142.0 einwandfrei funktioniert. Alle AltGr- Sequenzen funktionieren korrekt.
Nur die Store-Version des Terminals funktioniert nicht. Könnte der AzureConnector hier schuld sein, da ich ihn ausgeschlossen habe? (Ich meine, ich bezweifle, dass dies der Fall ist, aber nur um sicherzugehen ...)

@ DHowett-MSFT @miniksa Können Sie (oder jemand) die Store-Version von v0.3.2142.0 erneut überprüfen und mit lokal erstellten Versionen vergleichen?

Ich habe das gleiche Problem. Das Terminal kann mit diesem Problem nicht verwendet werden, da AltGr ein Muss ist. Und warum ist dieser Thread geschlossen? Es sollte ein Thema mit höchster Priorität sein.

Und warum ist dieser Thread geschlossen?

@MasMedIm Bei näherer Betrachtung

@lhecker das ist sehr ungewöhnlich. Der Azure-Connector sollte nichts damit zu tun haben, da er sich in einer anderen Ebene befindet (Verbindung, keine Steuerung) ... aber das ist trotzdem interessant.

Können Sie (oder jemand) die Store-Version von v0.3.2142.0 erneut überprüfen und mit lokal erstellten Versionen vergleichen?

Die Version, in der das AltGr-Sonderzeichen funktioniert, ist die Store-Version

AltGr ( ~#{[|`\^@]}¤€ ) funktioniert hier einwandfrei mit einer französischen Tastatur, Windows 10 Version 1903 Build 18362.267 und Windows Terminal Preview 0.3.2142.0

@ sba923 Ich habe auch eine französische Tastatur und die gleiche Windows-Version. Die AltGr-Kombinationen , die nicht funktionieren, sind: & ~ # {[| `\ ^ € ù \
Mein Terminal wird ebenfalls aus dem Store heruntergeladen. Ich werde versuchen, es in lokal zu bauen, um zu sehen.

Nur um auf meine Situation einzugehen: Einige AltGr + Tastenkombinationen funktionieren tatsächlich, andere nicht.

Funktioniert nicht:

| Schlüssel | AltGr + Taste, erwartet: |
| ----- | ----------------------- |
| '2' | '@' |
| '3' | '£' |
| '4' | '$' |
| '7' | '{' |
| '8' | '[' |
| '9' | ']' |

Werke:

| Schlüssel | AltGr + Taste, erwartet: |
| ----- | ----------------------- |
| '0' | '}' |
| '´' | '|' |
| '<' | '\' |
| '¨' | '~' |
| 'e' | '€' |

Hinweis: '´', '¨' sind tote Schlüsseltypen.

System: Windows 10 64bit Home 1903 Build 10.0.18362.267
Windows Terminal: Vorschau v0.3.2142.0 - Store-Version
Tastaturlayout: Dänisch.

@MasMedIm , @ sba923 , @lhecker - Sind Ihre Windows-Versionen wie meine?
Edit: Vergiss meine Frage. Ich wollte dort eine wilde Gänsejagd beginnen ;-) , aber

@ DHowett-MSFT @ henrik-jensen et. al.: Ich habe die Ursache für die Regression gefunden. ¯ \ _ (ツ) _ / ¯
... und es macht uns alle hier zu einem Haufen Idioten, die es früher bemerkt haben. 😂

Das neue profiles.json enthält Verknüpfungen der Art Ctrl+Alt+[0-9] mit denen Sie schnell zu Tab 1-10 springen können.
Wenn Sie diese Verknüpfungen aus Ihrer Einstellungsdatei ( Strg ) entfernen , ist die Regression behoben.
Bestimmte Kombinationen wie AltGr E für € leider noch nie funktioniert, und jemand muss sich die notwendige Zeit nehmen, um dies zu beheben.

Aufgrund der Funktionsweise der alten Windows-APIs wird es schwierig sein, zuverlässig zwischen Strg- Alt- Tastenkombinationen und tatsächlichen AltGr- Tastendrücken zu unterscheiden, aber ich werde prüfen, ob die Situation irgendwie verbessert werden kann.

@lhecker 🥇 👍
Bestätigt. Jubii

Bestimmte Kombinationen wie AltGr E für € leider noch nie funktioniert, und jemand muss sich die notwendige Zeit nehmen, um dies zu beheben.

AltGr E -> '€' funktioniert auf meinem dänischen Tastaturlayout. Ich werde versuchen, ein deutsches Layout hinzuzufügen, um zu sehen, ob es in meinem Setup reproduzierbar ist.

Wie wäre es nur die Kugel zu beißen? Behalten Sie die alte CMD.EXE für ältere (DOS) Apps bei und entwerfen Sie das neue Terminal nur für die Zukunft? Nicht, dass Abwärtskompatibilität nicht großartig ist - aber manchmal muss man einfach Krawatten schneiden ...

@lhecker 🥇 👍
Bestätigt. Jubii

Bestimmte Kombinationen wie AltGr E für € leider noch nie funktioniert, und jemand muss sich die notwendige Zeit nehmen, um dies zu beheben.

AltGr E -> '€' funktioniert auf meinem dänischen Tastaturlayout. Ich werde versuchen, ein deutsches Layout hinzuzufügen, um zu sehen, ob es in meinem Setup reproduzierbar ist.

Installierte deutsche ~ Kezboard ~ ups, Tastatur :-) * und AltGr E -> '€' funktionieren in diesem Setup.

Bearbeiten: * 'z' / 'y' werden auf deutsch / dänischen Tastaturen getauscht.

Das neue profiles.json enthält Verknüpfungen der Art Ctrl+Alt+[0-9] mit denen Sie schnell zu Tab 1-10 springen können.

Aus irgendeinem Grund sind diese Verknüpfungen in meiner Einstellungsdatei alt + [0-9] und ich hatte das Problem nicht

Einige Fragen kommen mir jetzt in den Sinn:

• @lhecker Vielleicht sollten wir ein neues Problem für die Regression für erstellen und Sie können Ihre Patch-Lösung dazu hinzufügen? Bearbeiten: Großartig - @lhecker hat eine Pull-Anfrage # 2235 gestellt
• Ich frage mich, wo die Standardeinstellung ~ settings.json ~ profiles.json generiert wird. Es ist keine Ressource, also nehme ich an, dass es irgendwo fest codiert ist? Bearbeiten: fand es CascadiaSettings.cpp L369
• Welche alternativen Verknüpfungen sollten stattdessen gewählt werden? Vielleicht haben diejenigen, die @saadanerdetbare in seinen ~ settings.json ~ profiles.json (Waren sie die Standardeinstellung in Version 0.3.2142.0? Bearbeiten: Scheint so - # 2014)

@lhecker @ henrik-jensen das würde Sinn machen. Ich habe direkt nach der Veröffentlichung aus dem Store installiert und einige Änderungen an profiles.json Wenn das Update die Datei nicht überschrieb, weil sie benutzerdefiniert und nicht standardmäßig war, wurden die Tastenkombinationen Strg + Alt nicht angezeigt

@ DHowett-MSFT @ henrik-jensen et. al.: Ich habe die Ursache für die Regression gefunden. ¯_ (ツ) _ / ¯
... und es macht uns alle hier zu einem Haufen Idioten, die es früher bemerkt haben. 😂

Das neue profiles.json enthält Verknüpfungen der Art Ctrl+Alt+[0-9] mit denen Sie schnell zu Tab 1-10 springen können.
Wenn Sie diese Verknüpfungen aus Ihrer Einstellungsdatei (Strg) entfernen, ist die Regression behoben.
Bestimmte Kombinationen wie AltGrE für € leider noch nie funktioniert, und jemand muss sich die notwendige Zeit nehmen, um dies zu beheben.

Aufgrund der Funktionsweise der alten Windows-APIs wird es schwierig sein, zuverlässig zwischen CtrlAlt-Verknüpfungen und tatsächlichen AltGr-Tastendrücken zu unterscheiden, aber ich werde prüfen, ob die Situation irgendwie verbessert werden kann.

Ty für die Antwort, in der Tat war es die Strg + Alt + [0-9] Einstellungen

@saadanerdetbare , Ja, es wurde von Ihren Einstellungen auf die neuen hier # 2014 von @ zadjii-msft geändert

Ich bestätige, dass die neuen Verknüpfungen AltGr ( ~#{[|`\^@]} ) auf meiner französischen Tastatur beschädigen.

Der Grund, warum einige von uns die Regression nicht gesehen haben, hängt mit dem 0.3-Upgrade zusammen, bei dem ein vorhandenes profiles.json nicht überschrieben wird. Dies ist in

Hinweis: Wenn Sie das Terminal bereits vor dieser Version installiert haben, werden diese Tastenkombinationen standardmäßig erst angezeigt, wenn Sie Ihre Datei "profile.json" löschen und neu generieren lassen. Sie können Ihre ursprüngliche profile.json an anderer Stelle speichern und über Ihre Anpassungen kopieren oder diese Tastenkombinationen einfach manuell hinzufügen. Wir sind uns bewusst, dass dies keine ideale Erfahrung ist und arbeiten daran, dies zu verbessern.

Man kann Strg + Alt + Umschalt + Ziffer_ verwenden, obwohl das nicht sehr einfach einzugeben ist ...

@ Henrik-Jensen Ich öffnete # 2235.

@thorsig Sie haben bereits
Insbesondere angesichts der Tatsache, dass z. B. Bash unter Linux (wie die meisten Shells, die Sie möglicherweise in Zukunft unter Windows verwenden möchten) keine rohen Schlüsselcodes erhält, sondern regulären Text, der mit Escape-Sequenzen gefüllt ist. Escape-Sequenzen, die Ihr Terminal aus Tastaturereignissen generieren muss. Ihre Linux-Shell verarbeitet keine rohen Schlüsselcodes. Ihr Terminal tut es.
Bevor Sie fortfahren, sollten Sie zunächst verstehen, wie xterm und vt100 (und höher) funktionieren.
Und übrigens: Schlüsselcodes unter Linux sind auch nur eine virtuelle (! = Rohe) Abstraktion über Scancodes von Ihrer Tastatur - siehe keymaps.5 . Der einzige Unterschied besteht darin, dass unter Windows vor langer Zeit entschieden wurde, dass Strg + Alt mit AltGr identisch ist, da einige Tastaturen keine AltGr-Tasten hatten, man aber trotzdem irgendwie AltGr drücken wollte. Die Leute, die dies entschieden haben, könnten heutzutage über 60 Jahre alt sein. Dies zu ändern ist nicht trivial und hat nur einen unbedeutenden Vorteil (da Sie AltGr-Tastendrücke in der Praxis ohnehin schon erkennen können).

Ich bestätige, dass die neuen Verknüpfungen AltGr ( ~#{[|`\^@]} ) auf meiner französischen Tastatur beschädigen.

Der Grund, warum einige von uns die Regression nicht gesehen haben, hängt mit dem 0.3-Upgrade zusammen, bei dem ein vorhandenes profiles.json nicht überschrieben wird. Dies ist in

Hinweis: Wenn Sie das Terminal bereits vor dieser Version installiert haben, werden diese Tastenkombinationen standardmäßig erst angezeigt, wenn Sie Ihre Datei "profile.json" löschen und neu generieren lassen. Sie können Ihre ursprüngliche profile.json an anderer Stelle speichern und über Ihre Anpassungen kopieren oder diese Tastenkombinationen einfach manuell hinzufügen. Wir sind uns bewusst, dass dies keine ideale Erfahrung ist und arbeiten daran, dies zu verbessern.

Man kann Strg + Alt + Umschalt + Ziffer_ verwenden, obwohl das nicht sehr einfach einzugeben ist ...

Es ist einfacher, alt + _digit_ zu verwenden und es ähnelt den Verknüpfungen im Gnome-Terminal.
Es funktioniert auf meiner französischen Tastatur.

Wenn Sie Alt + Ziffer verwenden , beachten Sie, dass Sie diese Schlüssel nicht an eine Konsolenanwendung senden können.

: tada: Dieses Problem wurde in # 2235 Windows Terminal Preview v0.3.2171.0 .: tada:

Praktische Links:

• Versionshinweise
• Laden Sie den Download herunter

AltGr ( ~#{[|`\^@]}¤€ ) funktioniert hier einwandfrei mit einer französischen Tastatur, Windows 10 Version 1903 Build 18362.267, Windows Terminal Preview 0.3. 2171 .0 und die Tastenkombinationen zum Wechseln der Registerkarten auf Ctrl+Alt+digit .

Gut gemacht!

Danke für die Bestätigung!

Gern geschehen!

0.3.2171.0 Fix für mein System bestätigt - Dänische Tastatur Win10 Home 1903 Build 10.0.18362.267.
Löschte mein profiles.json , um die Standardeinstellungen zu erhalten, und jetzt funktioniert AltGr auch für eine Neuinstallation (nehme ich an).
Großartige Arbeit @lhecker und alle anderen Beteiligten.

Hallo, ich glaube ich habe dieses Problem in Version 0.7.

Ich kann den Schrägstrich auf meiner Tastatur auch nicht über die Zehnertastatur oder AltGr + Q (brasilianische ABTN2-Tastatur eines Samsung-Laptops ohne Fragezeichen / Schrägstrich) eingeben.

Bearbeiten: Ich kann keine AltGr-Taste eingeben.

Nach dem Entfernen einer älteren Version von PSReadline funktioniert jetzt alles.

FWIW, ich habe die angehängten PowerShell-Skripte geschrieben, um zu überprüfen, welche Versionen von PSReadline auf meinem System vorhanden sind / welche aktiv ist.

CheckPSReadLineStatus.zip

HTH

Gehen Sie wie folgt vor, um dasselbe Problem zu beheben, das von Beppler gemeldet wurde:

Nach dem Entfernen einer älteren Version von PSReadline funktioniert jetzt alles.

Aus der erhöhten Powershell-Sitzung:

Install-Module -Name PowerShellGet -Force
Exit

Von einer erhöhten cmd-Sitzung aus:
powershell -noprofile -command "Install-Module PSReadLine -Force -SkipPublisherCheck -AllowPrerelease"

Wie ist der Status dieses Problems?
Wenn man sich die verknüpften Probleme ansieht, scheint es behoben zu sein, aber es funktioniert immer noch nicht für mich. Um das ~ -Zeichen auf einem italienischen Tastaturlayout zu drucken, bin ich es gewohnt, Alt + 126 zu verwenden, dies hat jedoch je nach Typ des Terminals ein anderes Verhalten, aber in keinem von ihnen kann ich das ~ -Zeichen abrufen gedruckt, während direkt in der zugrunde liegenden Shell (git / cmd / Powershell / wsl nicht in das Windows-Terminal eingebettet) funktioniert wie erwartet

Dies passiert mir mit der neuesten Version des Windows-Terminals. Derzeit wird Folgendes geschrieben:

Windows Terminal (Preview)
Version: 0.8.10091.0)

@ilmax Ich habe die Alt + Numpad-Eingabe in # 3117 unterbrochen. Nachdem # 3117 zusammengeführt und das damit verbundene Problem behoben wurde, konnten wir daran arbeiten, die Numpad-Eingabe wieder in die Codebasis einzuführen.
Ich würde dies jedoch zu einem optionalen, konfigurierbaren Verhalten machen, da ich ziemlich sicher bin, dass die meisten potenziellen Benutzer der Terminal-App nicht mehr davon profitieren werden. Die App sollte daher standardmäßig alle möglichen Tastatureingaben an die Shell senden, damit Sie erweiterte vim usw.-Tastenkombinationen konfigurieren können.
Die Implementierung sollte ein bisschen einfacher sein, sobald # 4192 zusammengeführt wird. Sie müßten die zusätzliche Logik hinzufügen rechts hier und prüfen , ob die Alt - Taste (und nur die Alt - Taste) in gehalten wird states , während die Vkey vom numpad stammen im Gegensatz von den regulären Zifferntasten . Sie können jederzeit eine PR einreichen! 🙂

@lhecker danke für die schnelle Antwort, ich wollte nur den Stand wissen, weil jedes Problem, das ich gefunden habe, geschlossen wurde, aber das Problem immer noch da ist.
Ich bin mir nicht sicher, ob ich eine PR dazu erstellen werde. Ich habe mir den Code noch nie angesehen. Ich weiß also wirklich nicht, wo ich anfangen soll, trotz Ihres Vorschlags.

Ich wollte nur wissen, wie ich meinen Workflow für git rebase -i reparieren kann, weil ich jetzt so etwas wie Notepad ++ öffnen, das Zeichen ~ eingeben, kopieren und in das Terminal einfügen muss.

Nur damit ich verstehe: Sie sind in einem Thread über AltGr mit einer Frage zu _alt + numpad sequence_? Dies kann der Grund sein, warum alle gefundenen Threads geschlossen sind: Das AltGr-Problem wurde behoben.

Ich glaube, wir haben ein separates Problem bei der Verfolgung von Alt + Numpad-Eingabeproblemen.

Ja, Sie haben Recht, entschuldigen Sie die Verwirrung. Ich denke, # 657 ist vielleicht die richtige