更新： Alt Grと組み合わせると、すべての桁で同じことが起こります。

あなたが知っている、これはおそらく私にあります。 KeyDownイベントを取得したときに、TermControl.cppのどこかでAltGRコンボのvkeyが正しく取得されていない可能性があります。

ちょっと無関係ですが、gif ましたか？

@watermelonpizza私が使用カルナックのキーを押すと表示するScreenToGifをウィンドウをキャプチャします。

ああ、カルナック、すごいありがとう！ 私はそれを私のグッズのリストに追加します:)

これは＃487の複製だと思います。

おっと、左手は右手が何をしているのかわからないようです、そして私はちょうど円形の複製リンクを作成しました。

この問題は、ハンガリー語のキーボードレイアウトを使用するWindowsバージョン10.0.18362.30で確認できます。 使用しているコンソールによって、動作は異なります。

• cmd：文字を書き込むだけですが、大文字です
• PowerShell：何もしません
• git bash：何も書きませんが、デフォルトのビープ音を鳴らします

@ zadjii-msft terminalInput.cppあなたの（？）AltGr関連のコメントを見つけました。
私のドイツ語キーボードのコントロールキーの状態があるLEFT_CTRL_PRESSED | LEFT_ALT_PRESSEDの代わりに、一見予想のLEFT_CTRL_PRESSED | RIGHT_ALT_PRESSEDけれども。
さらに、押された仮想キーは、すでに変換されたUnicode文字ではなく、たとえば「Q」です。

したがって、私は交換しました...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
と...

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

...そしてそれは機能します！ 今のところ。 😅GoogleによるとAltGr処理に対してより堅牢なWM_CHAR / _CharacterHandlerに処理を委任します。 （？）（私はまだWindowsプログラミングにあまり詳しくありません。）
これについてどう思いますか？ PRを提出する必要がありますか？

@lhecker素晴らしい！ 今、これは実際に使用可能です🎉

@lheckerはい、PRを送信してください。 ドイツ語のキーボードでは、現在パイプを入力できないため、端末が少し使いづらくなっています。

しかし、私の変更は間違っているように感じます。 すべての文字がWM_CHAR処理されないのには理由があるはずですよね？
そのため、最初に@ zadjii-msftまたは@ DHowett-MSFTのフィードバックを待ちたいと思います。 おもう？ 😅

実際の原因はTerminal.cppにあります

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

ここでは、RIGHT_ALT_PRESSEDが正しく検出されないことがわかります。これにより、TerminalInput :: HandleKeyのkeyEvent.IsAltGrPressedがfalseを返します。

ところで、修飾子の状態は、TermControl :: _ KeyDownHandler（）の_GetPressedModifierKeys（）によって取得されます。 ブール値の代わりに、修飾子の状態を直接SendKeyEventに渡して、左/右Ctrl、左/右Alt、左/右Shiftを後で押すかどうかを決定できます。

また、VirtualKeyには、TermControl :: _ GetPressedModifierKeys（）で使用できる次のように定義されています。

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

ああいいキャッチ@sagood！
残念ながら、この問題を修正するだけでは、私が見る限りでは十分ではありません...
TerminalInput::HandleKeyは、AltGrが押されたときに、OSがすでに「UnicodeCharを適切な代替値に事前変換」していることを前提としているようです。これは、ドイツ語キーボードのAltGr + Q（= @）などには当てはまりません。
IsAltGrPressed()周りの現在のロジックは、すでにちょっと欠陥があります。

@lhecker代わりにRIGHT_ALT_PRESSEDを使用してDWORD修飾子を初期化しようとしました。 AltGr + '+'（=〜）をテストしましたが、コンソールに正しく表示されます。
AltGr + <（= |）も機能します。

しかし、AltGr + Qは実際には機能していないようです。 変だ。
AltGr + E（=€）も機能しません。

新しいc＃UWPを設定すると、AltGrを使用しているときのキーシーケンスは次のようになります。

Menu
Control
Q

（例としてAltGr + Qを取り上げます）

さらにデバッグすると、以下に示すように、terminalInput.cppからTerminalInput :: HandleKeyの最初の条件ブランチを実行するようにプログラムに強制すると、

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が機能します。

ドイツ語キーボードの\のAltGr +ßはどうですか、同じ問題があります

すべてのAltGrキーボードの組み合わせは、同じ問題の影響を受けます。

これについて何か進展はありますか？ 動作を再現することはできましたが、AltGrケースを実際にどのように処理する

• ドイツ語のキーボードで、AltGrが実際にLeft_CTRL && LEFT_ALTに変換され、CMD、PS、およびWSLでテストされていることを確認しました
• バグは不合格のテストに関連しているようです。 ドイツ語のキーボードに切り替えると、次のテストは失敗しますが、英語のキーボードは合格です。
  
  
  
  • InputEngingeTest:C0
  
  
  • set10までのInputTest::TerminalInputModifierKeyTests#metadataSet3
  
  

@lhecker好奇心から、 isAltGrPressed()をisAltPressed() && isCtrlPressed()に置き換えるという最初のアイデアを適用し、次のことを確認しました。

• @と€を含むCMDで機能しますが、PSまたはWSLでは機能しません
• 実際には不合格のテストを修正しません
• しかし、代わりに英語キーボードのMouseInputTest::SgrModeTests#metadataSet20を壊します。

問題をさらに絞り込むことはあまりできませんでしたが、この情報は役立つかもしれないと思いました。

それは非常に興味深い@MattKuhrです。 @と€は、PowerShellとWSLの両方で実際に機能します。 🤔
（100％確実にするために-これは現在のマスター67f68ebの

確かに、現在のマスターに更新して、もう一度テストしました。 PSの€を除いて、特殊文字が機能するようになりました。

以前に観察した動作の原因がわかりません。まったく同じコード変更が使用されました。 何度もテストしたり、その間にインストールされたWindows Updateの一部が影響を及ぼしたりしたにもかかわらず、テスト中に展開で何かを台無しにしたのではないかと考え始めています。

これは、現在のマスターでテストするときにドイツ語のキーボードを設定したスクリーンキャプチャです。

デバッグとリリース（x64）、Win10.0.18362.116の両方でテストしました。 また、システム言語を変更してみましたが、効果はありませんでした。 この1つの特定のケースでのみ、€が正しく翻訳されないのは少し奇妙に思えます。

たとえば、最初にRemove-Module PSReadline実行すると、PowerShellで機能し始めますか？ （心配しないでください。現在のセッションにのみ影響します。）もしそうなら、私たちはいくつかのアイデアを持っています！

@ DHowett-MSFT 18362.113のドイツ語キーボードレイアウトを変更せずに、昨日のマスターチェックアウトのビルドでテストしました（言語設定は英語です）

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

通常の文字の場合、AltGrはシフトのように機能します。 その他の文字は、修飾子なしで値に残されます。

@ DHowett-MSFT実際には😃

他のキーは機能し続けます。 また、以前は小さな3は通常の3として記述されていましたが、下のスクリーンショットに示すように、正しく表示されるようになりました。

こんにちは、

これはフィンランドのQWERTYレイアウトにも影響し、@、|、{}、[]、〜、\などのすべてのAltGrの組み合わせが使用できなくなります。

これらはすべて、WSL、cmd、およびpowershellの@lheckerからのパッチで正常に機能するようです。 ありがとう@lhecker ！

こんにちは、それはフランスのAzertyキーボードレイアウトでも機能します。 ありがとう@lhecker

スイスドイツ語キーボードの「AltGr + <」（バックスラッシュですが、結果は「<」）などのAltGrの組み合わせに問題があります。

この号のタイトルを更新して、何を追跡しているのかを通行人にわかりやすくしました。

@ zadjii-msft terminalInput.cppであなたの（？）AltGr関連のコメントを見つけました。
したがって、私は交換しました...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
と...
if（keyEvent.IsAltPressed（）&& keyEvent.IsCtrlPressed（））
{{
falseを返します。
}
...そしてそれは機能します！ 今のところ。 😅

この変更により、フランス語のキーボードで使用可能なAltGrも使用できるようになります。 これまでにCMD、Windows PowerShell 5.1、PowerShell Core 6.2.1でテスト済み（どちらも非公式のPSReadline 2.0.0beta4で、VScodeで作業する必要があります）

この変更により、フランス語のキーボードで使用可能なAltGrも使用できるようになります。 これまでにCMD、Windows PowerShell 5.1、PowerShell Core 6.2.1でテスト済み（どちらも非公式のPSReadline 2.0.0beta4で、VScodeで作業する必要があります）

PSReadlineのバージョンを確認し、2.0.0から2.0.0-beta4にアップグレードしたところ、うまくいきました。現在、€と³は、5.1と6.2.1の両方のPSでも正しく機能しています。 😄

PSReadlineに関連しているように見えるが、AltGrやキーボードレイアウトに直接関連していない別のバグを見つけましたが。 以下に示すように、ターミナルではCTRL 2は"変換され、 CTRL 7 （GERレイアウトでは、米国ではCTRL / ）から^_変換されます。

最初のケースでは、PSReadlineを削除するとうまくいきますが、2番目のケースではうまくいきません。 他の数字と特殊文字キーを試しましたが、これまでに見つけたのはこれら2つだけでした。 動作は5.1と6.2.1で同じです。 PSReadlineは2.0.0beta4です。

これについては別の問題を開く必要がありますか？

ポルトガル語（ポルトガル語）のキーボードにも関連する問題があります。
予想：Alt Gr + 2/3/4/7/8/9/0は@£§{[]}を出力し、Alt Gr + eは€を取得する必要があります

Windowsターミナル：
-PSコア：Alt Gr +桁は、7つの出力を除いてPSReadlineDigitFunctionをトリガーします^ _
-PSコア：Alt Gr +€は何もしません
-Windows Powershell：PSCoreと同じ
-CMD：Alt Gr +桁は、7つの出力を除いて桁を出力します^ _
-CMD：Alt Gr + eはEを出力します

内蔵コンソール：
PSコア：Alt Gr + 2/3/4/7/8/9/0出力@£§{[]}、Alt Gr + Eは何もしません
Windows PowerShell：PSCoreと同じ
CMD-すべての作品

Windows 10 1903 18362.116
PSコア6.2
Windowsターミナル0.1.1431.0
PSReadline 2.0.0

「 AltGr 」キーの組み合わせが機能しない場合の実際の回避策は、

しかし、これも機能しません！

657「Alt +テンキーが機能しない」

これに取り組む人は誰でも、この密接に関連するものにも取り組むことをお勧めします。

アイスランド語のキーボードでもこれを確認できます。 AltGrを使用してこれらを記述します。
@ |€{[]} \ µ〜 `^

補足：この問題は、ほぼすべてのMicrosoftコマンドラインテクノロジで発生します。 これはすでにOpenSSHで発生し、同様の問題がPSReadlineで発生しました。ここでも、AltGrの組み合わせが機能しない場合があります。

コマンドラインで何かを試すたびに、入力の問題が常に発生します。 ホームエンドが機能せず、SSH経由でも機能しないため、リモートセッションでPowerShellを使用することはできません。

どういうわけか、この端末-SSH-PSReadlineの三角形は呪われています。

ここでは、PT-BRキーボードレイアウトを使用しています。

取得するには/私が使用してAlt Gr + Q

ターミナルで使用する場合は、元に戻すコマンドのように機能します。 最後のコマンド/文字/単語を再入力するだけです

@MathiasMagnus

AltGrの組み合わせはどれも機能しません。

AltGrの組み合わせはどれも機能しないということですか？

たとえば、最初にRemove-Module PSReadline実行すると、PowerShellで機能し始めますか？ （心配しないでください。現在のセッションにのみ影響します。）もしそうなら、私たちはいくつかのアイデアを持っています！

私にはうまくいきません（フランスのAZERTYレイアウト）

だから.....何か新しいアイデアはありますか？ 修正のため...

`` `c ++
if（keyEvent.IsAltPressed（）&& keyEvent.IsCtrlPressed（））
{{
falseを返します。
}
..。

私のために働いていませんでした<。<

編集：

マシンで定義されているメインのキーボード言語を検出してから、 @ microsoftで再バインドを実行する方が

@Hedrautaコードの変更がうまくいかないのは奇妙です。 どのキーボードレイアウトを使用していますか？ AltGrと組み合わせて使用​​されるxxx値に対して、通常のCMDでCtrl+Alt+xxxは何をしますか？ 私が覚えている限り、 Ctrl+Altは常にAltGrと同等である必要があります...

それで、いくつかのテストデータを収集するために：私にとって、 @ lheckerによるパッチは

ターミナル| Alt Gr + ß？\ | Strg + Alt + ß？\
-|-|-
レガシーcmd.exe | \ | \
レガシーpwsh.exe | \ | \
Windowsターミナル、 master 、 cmd.exe | ß | ß
Windowsターミナル、 master 、 pwsh.exe | _（なし）_ | _（なし）_
Windowsターミナル、 master + @lheckerによるパッチ、 cmd.exe | \ | \
Windowsターミナル、 master + @lheckerによるパッチ、 pwsh.exe | \ | \

https://github.com/microsoft/terminal/issues/521#issuecomment-501148984と同じ結果
@lheckerによるパッチで

しかし、 pwshでは、€-記号はまだドイツ語のレイアウトでは機能していません。

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コードの変更がうまくいかないのは奇妙です。 どのキーボードレイアウトを使用していますか？ AltGrと組み合わせて使用​​されるxxx値に対して、通常のCMDでCtrl+Alt+xxxは何をしますか？ 私が覚えている限り、 Ctrl+Altは常にAltGrと同等である必要があります...

それも私を助けませんでした...
そのコードに基づいて独自の回避策を作成しようとしましたが、今のところ運がありません...

PT-BRキーボードレイアウトを使用して、次の組み合わせを試しています。

CMD、Powershell、WSL.exe
AltGr + Q = /

Windowsターミナルを使用する場合
WSL： AltGr + Q =元に戻すコマンドのように機能し、最後に入力した文字を書き換えます。
Powershell、CMD： AltGr + Q =この奇妙な文字を生成しますは^_ように出力されます

編集：
視覚化を支援するには：

正しい入力は次のようになります
AltGr + Q = /
AltGr + W = ?
AltGr + [ = ª
AltGr + ] = º

@ renatop7 AltGrの代わりに

@ renatop7 AltGrの代わりに

同じ結果

そして、ターミナルの外、つまり標準のCMDまたはWindowsPowershellまたはPowershellCore内ですか？ CtrlAltは常にAltGrのように動作しますか？

そして、ターミナルの外、つまり標準のCMDまたはWindowsPowershellまたはPowershellCore内ですか？ CtrlAltは常にAltGrのように動作しますか？

はい、ターミナルの外では完全に機能します。
AltGrまたはCtrl + Altを使用すると、期待どおりの結果が得られます。

15分前に取得：まったく機能していません
さて、マイクロソフトはこの問題に関連する解決策にも取り組んでいますか？

@Hedrautaコードの変更がうまくいかないのは奇妙です。 どのキーボードレイアウトを使用していますか？ AltGrと組み合わせて使用​​されるxxx値に対して、通常のCMDでCtrl+Alt+xxxは何をしますか？ 私が覚えている限り、 Ctrl+Altは常にAltGrと同等である必要があります...

うーん、標準ドイツ語？ ここにそれがどのように見えるかからの画面： https ：
マクロを介してキーを入力しようとします...テスト

まるで、私の左のaltはShiftであり、Altではありません...
試した結果
Ctrl + Q ^ Q
CTRL + Alt + QQ
ちょうどQq
Alt + QQ

コメントを更新してgifを試してみます
編集：それをgifしようとしているときに、私のAlt-Keyが間違って認識されていることに気づきました....仮想キーがどこで定義されているか誰もが知っていますか？ それも調べます;）しかし、私はc ++や....コーディングの経験はあまりありません;）

cpp noobとしての私のために、いくつかのファイルをチェックしたところ、
C：\ Program Files（x86）\ Windows Kits \ 10 \ Include \ 10.0.17763.0 \ um \ WinUser.h
だから....ドイツのレイアウトの場合、VK_Menuは存在しませんよね？ 私たちはVK_LMENUを所有しているだけですよね？
私はいくつかの変更を試み、いくつかのテストを行います...後で結果を編集します
編集1：システム全体を再構築するように、構築に時間がかかります
編集2：すべてをビルドした後、それは機能していません...しかし、VK_RMENUはAltGrであり、VK_LMENUは@または\を取得するために押されたいキーであることに気付きました
VK_MENUも機能しているように見えますが、割り当てが間違っている可能性があります
これはちょっと混乱します。クリーンなフェッチ、再構築、仮眠の後にこれをチェックします

以下のためにドイツ語のキーボードレイアウト、それはさらに悪いですのでAlt Gr + Qれなければならないだけで出力@ 、現在のライン入力を削除します。
これはwslでは発生しません。また、WT用に構成されていることもわかりません。では、これはどのように発生するのでしょうか。

まだ問題：
キーボード：ベルギー（ポイント）AZERTY、通常のシェルで動作
ウィンバー：18362.175
ターミナルバージョン：0.2.1715.0

_この問題にも取り組んでいるとのコメントはご遠慮ください。_

これまでのところ、この問題が大量のキーの組み合わせに影響を及ぼし、同じように大量の言語、Windowsバージョン、キーボードなどに対して、同じように大量の予期しない副作用が発生する可能性があることは誰にとっても明らかです。
コメントの半分以上は#metooスタイルであり、この問題の修正にはまったく役立ちません。
役立つコメントを目立たなくするだけです。
実際に欠けていて非常に役立つのは、知識のあるWindows開発者がこの問題に取り組み、PRを提出することです。

それまでの間、このプロジェクトをコンパイルできるすべての人が、このコードを自由に置き換えることができます： https ：

私のこの実験的な修正で：

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

これにより、ドイツ語（または同様の）キーボードの@{}[]などの文字を含む、ほとんどのキーボード言語のほとんどのキーの組み合わせが修正されます。

PS：私はマイクロソフトとはいかなる形でも提携していません。私はこれらの「#metoo」コメントをノイズが多すぎて非生産的であると個人的に考えているため、これを書いています。 🙂
PPS：なぜ自分でPRを提出しないのか疑問に思う人もいると思います。 自分自身を引用すると、 「私の変更は間違っているように感じます。すべての文字がWM_CHAR処理されないのには理由があるはずですよね？」 つまり、上記の修正の欠点と、それを適切に行う方法が実際にはわかりません。

PPS：なぜ自分でPRを提出しないのか疑問に思う人もいると思います。 自分の言葉を引用すると、「私の変更は間違っているように感じます。すべての文字がWM_CHARによって処理されないのには理由があるはずですよね？」 つまり、上記の修正の欠点と、それを適切に行う方法が実際にはわかりません。

知る方法の1つは、PRを提出し、チームによって修正されることです。 少しやり過ぎですが、物事が速く動くと思います。

@ NatoBoram😤👉＃1436

VtPipeTermなどのサンプルアプリケーションを使用する場合、alt-grキーがそこで機能することに注意してください。

@HBelusca VtPipeTermは新しいUWPターミナルに基づいていないため、この問題は発生しません。
根本的な問題の1つの可能な説明については、＃1436を読むことができます。

@lheckerこれはCascadiaに基づいていませんが、同じ基盤となる疑似

ありがとう@HBelusca

特別なキーは、ターミナルやWindowsアプリで何年も機能してきました。 2019年になぜこの問題が発生するのですか？ ターミナルプログラムの入力システムを完全に再実装しましたか？ それを実行して、数年前に修正されたバグを再導入する必要があったことを願っています：s。 この問題は、コードページ、言語キーボードマッピング、およびWindows固有のキーが原因で、Linuxで一般的でしたが、この重大なバグは、ストアで入手でき、どこでも公開されているアプリケーションのプレビューバージョンにあります。

@ifilgudこれはプレビューの理由でストアで入手できるプレビューバージョンです。 この問題はトリアージされており、PRも提出されているため、文句を言うためだけにこの問題についてコメントする必要はありません。

@patriksvensson私は主に不平を言っていて、それは「礼儀正しく」ではないことを知っていますが、このようなバグの理由を説明するための技術的な理由も求めています。 ほぼ完成したバージョン（プレビュー）で修正するマイナーエラーがあると思っていましたが、最初から作成して英語でのみテストしない限り、ターミナルの進化に存在すべきではなかったエラーはありませんでした（それが理由だと思います）最初のアルファバージョンではこれを検出しません）。 ターミナルを開いて、2番目のコマンド（最初は「dir」）として「cd \」を書き込もうとしましたが、機能しませんでした。 ソフトウェア開発者として、これは私に大きな影響を与えました。

@lheckerこれまでのところ、実験的な修正を適用した後はとても良いです。 どうもありがとう！！

これを指摘し、すでに修正してくれたすべてのpplに感謝します。 🌷

MSストアアプリはどのくらいの頻度で更新されますか？
では、いつストアアプリで修正されると期待できますか？

ターミナルで作業したいのですが、ドイツ語のキーボードでは、altgrなしで{ }を書くことさえできません。 😅

ノルウェーのブークモール（nb-NO）キーボードレイアウトでも同じ問題が発生しました。 []または{}または$を作成できません。 PowerShellは基本的にそれらなしでは壊れています。
Windows 10 190318362.175でUWP / MicrosoftStoreバージョン0.2.1715.0を使用する。

AltGrを介したhu_HUレイアウト： \ | & @ $ ; # <> {} []ブレース、山かっこ、角かっこ、円記号、パイプ、ドル記号、ハッシュマーク、「at」、「and」、セミコロンを開く頻度を意味します...ああ待って、すべての行?? :)

_この問題にも取り組んでいるとのコメントはご遠慮ください。_

これまでのところ、この問題が大量のキーの組み合わせに影響を及ぼし、同じように大量の言語、Windowsバージョン、キーボードなどに対して、同じように大量の予期しない副作用が発生する可能性があることは誰にとっても明らかです。
コメントの半分以上は#metooスタイルであり、この問題の修正にはまったく役立ちません。
_役立つコメントだけが見えにくくなります_。

更新： Alt Grと組み合わせると、すべての桁で同じことが起こります。

このgifレコードをどのように作成しましたか？

@ Karl-スレッドをさらに下に見てください。

@ DHowett-MSFT下部にメッセージを表示してこのスレッドをロックすることをお勧めします

この問題が発生している間、ターミナルはPowershellでは非常に使用できません。
修正されるまで控えることができない人のために、Windows 101903の回避策を紹介したいと思います。

回避策：
Windowsキー+を使用します。
特殊文字タブに移動して、キャラクターを選択します
ターミナルに切り替えて、文字を挿入します

ロックを解除したままにしておくと、機能しない個々のキーを報告するスペースが提供されるため、機能しない個々のキーに関する個々の_問題_の提出を停止できます。 私は引き裂かれています。

特殊文字が期待どおりに動作しない場合が増える可能性があります。 デンマーク語のキーボードで@文字を作成する場合、3つの方法があります。AltGr+ 2、左Ctrl +左Alt + 2、または左Alt + Numpad 64
最初の2つのオプションは、OPが報告した結果を示します。
最後のオプションはPowerShellで行います：
Onpres Left Alt + Numpad 64 digit-argument: 64
Onrelease Left Alt：64 @文字
cmdで
Onpres Left Alt + Numpad 64： 64
Onrelease Left Alt： @結果64@
wslで
Onpres Left Alt + Numpad 64： (arg: 64)
Onrelease Left Alt：64 @文字

良い点@saadanerdetbare！

Alt + Numpadの問題は、新しいターミナル（Cascadia）が、これらのコードを入力したときに適切なエスケープコードをシェルに送信するという事実に起因しているようです。 しかし同時に、アプリケーションの別の部分は、このケースを処理し、Alt + Numpadコードを適切な文字に変換し、それをシェルに挿入することです。 これにより、@文字が64回繰り返されるという面白い副作用が発生します（次のバイトがシェルに送信されたため： \x1b6\x1b4@ ）。

これらの2行の間に次の追加コードを追加することで、これを試すことができ

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

これにより、Cascadiaがこれらのエスケープコードをシェルに送信するのを停止します。 その後、文字（@など）が正常に表示されます。
または、同じ効果を得るために、このコードブロックを削除することもできます。

〜 @ saadanerdetbareこれはAltGrの機能とは関係のないバグであるため、問題の詳細を示す別の問題を作成できれば非常に素晴らしいでしょう。 🙂〜
👉＃1401
最初に他の問題を検索する必要があります。 🤦‍♂️

PS：コミュニティが未知の他の人に頼るのではなく、自分でこれらのことをデバッグする準備ができているのを見ると、個人的に非常に誇りに思うでしょう。 🙈🙂

@saadanerdetbareは、新しい問題の提出を

私はまだプレビューアプリでこれを経験しています、私はベルギーのキーボードを持っています、@を書くことは不可能です

@solispauwelsは、次のリリースまで待つ必要があります（または、今のところ、現在のマスターブランチを自分でビルドします）。

こんにちは、私はドイツ語のキーボードでこのコミットをテストしました。€記号を出力するaltgr-Eを除いて、すべてが機能します。 正直なところ、これは端末ではあまり必要ありませんが、とにかく言及するかもしれないと思いました。 しかし、µのaltgr-mのような他のものは機能します。

更新：無視できると思います。€記号は標準のPowerShellでも機能しないため、端末の障害ではないようです。これは以前に確認する必要があります。

ここではすべてがフランス語のキーボードで機能しているようです。 AltGr+é"'(-è_çà)=$eは期待される~#{[|`\^@]}¤€

フランス語のキーボードも使用していますが（ベルギーにいます）、AltGr +で問題が発生しています。文字。 |＃{} @などは機能しません。 Windows 10v1903でWindowsストア0.2.1715.0の最新リリースを使用しています。

@meuterは、次のリリースまで待つ必要があります（または、今のところ、現在のマスターブランチを自分でビルドします）。

＃1436の修正は、MicrosoftStoreで入手できるプレビューバージョンにはまだ含まれていません。

@antoineco @ sba923ありがとう、それが私が考えたものです。 リポジトリのクローンを作成しました。 vs2017のアップデートが終了したらすぐに、ソースから再構築します:-)

これに一生懸命取り組み、受信トレイにレポートを記入していただき、ありがとうございます。 修正を送信してくれた@lheckerに特に感謝します！ v0.2.1831.0サービスリリースとともにストアに送信しました。 ストアが処理するのに時間がかかる場合があります。

ストアに送信しました

したがって、アプリをWindowsストアに公開した経験から、3日から3週間かかるはずです😉

ストアに送信しました

したがって、アプリをWindowsストアに公開した経験から、3日から3週間かかるはずです😉

6時間未満のようです。 😋

とにかく、私のスウェーデン語のキーボードでは、すべてがうまくいくようです。 👍

ドイツ語キーボードで動作するようになりました👍

バージョン0.2.1831.0のフランス語キーボードで動作します！ ありがとう

バージョン0.2.1831.0のフランス語キーボードで動作します！ ありがとう

確認済み！

よくやった！

@ DHowett-MSFT v0.2.1831.0にはこの修正が含まれているようですが、電力線フォントやコピー/貼り付けキービングなどの他のバグ修正は含まれていませんが、これは正常ですか？

Alt-Grが機能することを確認しましたが、代わりにCtrl-Altを使用して同じキーボードキーにアクセスすると、確実に機能しません（あるとしても）。

バージョン0.2.1831.0では、AltGrの組み合わせがフィンランド語のキーボードで機能するようになりました。

@solispauwelsバージョン

1803以降のOSの多くは、Windowsストアバージョン11905.1001.4.0でバグに直面する可能性があることに注意してください。
ストアはダウンロード対象としてアプリを「スタック」しますが（画像を参照）、自動ダウンロードが有効になっていてネットワークが従量制接続でない場合でも、アプリはダウンロードされません。

影響を受けるユーザーは、Microsoftストアで[更新の確認]を押して、最終的に修正されたストアアプリを取得し、保留中のすべてのアプリのダウンロードを開始する必要があります。

この問題は、新しいバージョンのターミナルで修正されることを確認しました。 どうもありがとう。

これも修正されていることを確認できます。 問題の固定を解除することをお勧めします。

少なくともスペイン語のキーボードでは、AltGr + eであるユーロキーを除いて機能します。 残りの組み合わせは正しく機能します

@ifilgudから

少なくともスペイン語のキーボードでは、AltGr + eであるユーロキーを除いて機能します。 残りの組み合わせは正しく機能します

「ベルギー（期間）」AZERTYキーボードを使用して2019-07-08の最新バージョンを使用してWindows 10 1903（18362.175）でテストされました。

テスト結果：

• ユーロ（€）通貨記号を含む、キーボードで使用できるすべての組み合わせは、Windowsターミナルでデフォルトとして構成されている3つのコンソールのうちの2つで動作します：PowerShellCoreと 'cmd'（Windowsコマンドプロンプト）
• 「WindowsPowerShell」でのみ、ユーロ記号（€）は機能し
  
  
  
  • しかしそれは、PowerShellのクラシックコンソールでの作業はWindowsのスタートから直接起動にもしません。
  
  

ImoこれはWindowsPowerShellに関連する新しい問題であり、そのコンソールをホストしているWindowsターミナルに固有のものではありません。

@DeChristの観察を確認します。 一方、Ctrl-Alt +（Key）を押すと、期待どおりに機能しません（AltGrの代わりにこの組み合わせを使用する場合）。

ここで、Windows Terminal Previewバージョン0.2.1831.0を実行しているWindows10ビルド18362.175で、フランス語のキーボードを使用すると、 AltGr+Eは、次のすべてのシェルで€します。

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

_PowerShell_でAltGr問題が残っている人は、実行しているPSReadLineバージョンを確認できますか？

$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試してみてください：

1. PSReadLineの無効化
2. 最新のbeta4にアップグレードします。https：//github.com/PowerShell/PSReadLineを参照して

• Windows 10 1903
• Windowsターミナル0.2.1831.0
• PowerShell v7（PSReadline 2.0.0-beta4を含む）
• ドイツ語のQWERTZキーボードレイアウト

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

RDPセッションが開いているとAltGr + Qが機能しなくなるという、Microsoftが少なくとも10年間無視してきた、 mstsc関連する別のバグがあるため、これは特に苛立たしいことです。 このような状況でもCtrl + Alt + Qは機能するため、多くの人が回避策として使用しています。

Microsoftがすべきことは、キーボードストリームに触れないことです。

シェル（explorer.exe）は、必要なキー押下をすべてキャッチし、その他すべてをダウンストリームに渡す必要があります。
Terminal.exeは、最終的にはAlt-F4のみをキャッチする必要があり、おそらくそれもキャッチしないはずです。explorer.exeは実際にそれをキャッチして、アクティブなプロセスに適用する必要があります。

つまり、Terminal.exeはキーボードストリームのみを取得し、アクティブな子プロセスに渡す必要があります。 他には何もありません。

CMD.exe [command.com]は、必要なものをキャッチし、残りを自身の子に渡す方法を知っている必要があります。

WSLは、可能な限り多くの生の入力を取得する必要があります。 AltGrをマンハンドリングしないでください。 Ctrl-AltとAltGrは同じキーボードシーケンスではありません。 Linuxには、ctrl-alt -...を使用したショートカットがあり、AltGr -...とは異なる結果が生成されます。

それを適切に行う機会は1つだけです。 ほぼ40年ぶりのチャンス。 その機会を無駄にしないでください-マイクロソフト、私はあなたを見ています:)

@thorsigああ、もしWin32入力スタックが40年前に設計されたときに私たちがあなたを

• 文字として、修飾子なし（したがって、ALTを検出してターミナルパイプを介して送信することはできません）またはキーを押す方向
• スキャンコードとして、修飾子と方向がありますが、実際には_物理的なキーの場所_の単なる表現です

オペレーティングシステムレベルより下を調べ始めると、スキャンコードは「可能な限り生の入力」モードになります。 ただし、テキスト入力を必要とするアプリケーションに渡す前に、少し調理する必要があります。 （編集して追加:)ターミナルアプリケーションは、実際にはテキストとしての入力を好みます。 SSH接続を介してスキャンコードを送信することはできません！ できたとしても、受信者は翻訳を行うためにキーボードのレイアウトを理解する必要があります。 おそらくヘッドレスマシンにはキーボードレイアウトがありません。 （/編集）

「彼らが押した文字通りの文字を取得して送信する」のと同じくらい簡単であれば、私たちがまさにそれを行うことを信頼する必要があります。 私たちはクレイジーな人々なので、クレイジーなソリューションを設計することはありません！ ：スマイル：

当時、入力ストリームを処理する方法についてはあまり手がかりがなかったかもしれませんが、私は周りにいました。

ただし、Linuxはデフォルトで生のキーコードで動作するため、問題はありません。 ただし、sshがターミナルアプリケーションによって直接実行されることはないため、ssh接続の例には欠陥があります。シェルに到達するものを担当するシェル（またはWSLなどのOS抽象化全体）が内部にあります。

あなたが述べていることが正しいとすれば、これまでにWindows用に作成されたすべてのアプリケーション（エクスプローラー上で実行）は、独自の固有のキーボード処理を実装する必要があります。 彼らはしません。 それは上流と下流の世話をしているからです。

私はコードを見て、「SMH」のシェアを持っていました。 もっと上手くできますか？ 与えられた時間、おそらく。 私はそれについて雌犬にする余裕がありますか？ 自分でやる時間がないことを考えると、おそらくそうではないでしょう。

私はまだ言及する価値があると感じました、それはそのまま過剰に設計されており、それはある時点で（おそらく遅かれ早かれ）下流で問題を引き起こすでしょう。

当時、入力ストリームを処理する方法についてはあまり手がかりがなかったかもしれませんが、私は周りにいました。

ただし、Linuxはデフォルトで生のキーコードで動作するため、問題はありません。 ただし、sshがターミナルアプリケーションによって直接実行されることはないため、ssh接続の例には欠陥があります。シェルに到達するものを担当するシェル（またはWSLなどのOS抽象化全体）が内部にあります。

WSLは特定の種類の翻訳を行いません。 conhost.exeまたはWindowsターミナル（または、XMingなどを介してグラフィカルアプリを実行している場合はGnomeターミナル）は、適切な変換を行ってptyに送信します。 そしてシェルでさえ...それはシェル自体がほとんどの仕事をしているのではありません。 これは、ターミナルドライバーとマスターエンドのアプリです（これも、conhost.exe、Windowsターミナル、必要に応じてCygwinターミナル、およびLinuxターミナルアプリのいずれかです）。

あなたが述べていることが正しいとすれば、これまでにWindows用に作成されたすべてのアプリケーション（エクスプローラー上で実行）は、独自の固有のキーボード処理を実装する必要があります。 彼らはしません。 それは上流と下流の世話をしているからです。

ほとんどのアプリは、実際には生のキーボード入力を気にしません。 これは、本質的に損失の多い方法で一部のWin32ライブラリを介して処理されます。 生のキーボード入力を直接使用しません。 物理的なレイアウト入力を正確に気にするゲームを除いて、ほとんどのアプリはキャラクターだけを気にします。 どちらの方法でも問題なく動作します。

私はコードを見て、「SMH」のシェアを持っていました。 もっと上手くできますか？ 与えられた時間、おそらく。 私はそれについて雌犬にする余裕がありますか？ 自分でやる時間がないことを考えると、おそらくそうではないでしょう。

私はまだ言及する価値があると感じました、それはそのまま過剰に設計されており、それはある時点で（おそらく遅かれ早かれ）下流で問題を引き起こすでしょう。

LinuxアナログであるGnome-Terminalを調べて、それがより単純か複雑かを確認することをお勧めします。 Xは実際にはGDI32または使用されているウィンドウAPIよりも奇妙なので、もっと複雑だと思います。

0.2.1831.0からの回帰はありますか？
デンマーク語のキーボードでは、Windows Terminal Previewv0.3.2142.0がAltGrに応答しません。

Windowsターミナル（プレビュー）
バージョン：0.3.2142.0
Microsoft Windows 1903 [バージョン10.0.18362.267]

私はデンマーク語のキーボードとv0.3.2142.0Windowsビルド10.0.18362.239を持っています。これは言語パックのない英語のオペレーティングシステムです。 Alt Gr特殊文字はここで機能しますが、Ctrl + Altシーケンスは機能しません

私はデンマーク語のキーボードとv0.3.2142.0Windowsビルド10.0.18362.239を持っています。これは言語パックのない英語のオペレーティングシステムです。 Alt Gr特殊文字はここで機能しますが、Ctrl + Altシーケンスは機能しません

私のOS：Win10 Home 1903 Build 10.0.18362.267
デンマーク語の言語パックがデフォルトですが、追加の米国の言語パックがインストールされたデンマーク語のオペレーティングシステム。
うーん-ビルド10.0.18362.267対10.0.18362.239-そこに手がかりはありますか？!!!

私のOS：Win10 Home 1903 Build 10.0.18362.267
デンマーク語の言語パックがデフォルトですが、追加の米国の言語パックがインストールされたデンマーク語のオペレーティングシステム。
うーん-ビルド10.0.18362.267対10.0.18362.239-そこに手がかりはありますか？!!!

すべての詳細を取得するには：
私は
Win 10 Enterprise en-US1903ビルド18362.239
デンマーク語キーボード、言語パックなし

米国の言語パックをデフォルトとして使用してアカウントにログインしようとしました。そこに端末をインストールし、デンマーク語のキーボードに切り替えて、選択した言語パックが影響を及ぼしているかどうかを確認しましたが、うまくいきませんでした。

これが知っている人の手がかりになるかどうかはわかりませんが、1809から1903にアップグレードする前に、オンスクリーンキーボード（ c:\windows\system32\osk.exe ）はすべてのコンホストアプリ、cmd.exe、ubuntu / wslで同じ動作を示しましたおよびpowershell.exe（AltGrを無視）ですが、1903年にこれは修正されたようです。

私は_some_ AltGrのシーケンスが動作しないことを確認することができます。
AltGr Q （= @ ）は私には機能しますが、たとえばAltGr 8 （= [ ）は機能しません。

この問題をデバッグするために、ストアバージョンv0.3.2142.0をローカルでビルドしました。 AzureConnectorの構築方法がわからなかったため、除外する必要がありました： https ：//gist.github.com/lhecker/320662cb3fda70af1ca58eabf9f2579a
👉ローカルで構築されたv0.3.2142.0は問題なく動作することがわかりました。 すべてのAltGrシーケンスは正しく機能します。
ターミナルのストアバージョンのみはそうではありません。 AzureConnectorを除外したので、ここで障害が発生する可能性はありますか？ （私はそれが事実であるとは思えませんが、念のために...）

@ DHowett-MSFT @miniksaあなた（または誰か）はv0.3.2142.0のストアバージョンを再チェックして、ローカルで構築されたものと比較できますか？

同じ問題があります。 AltGrは必須であるため、ターミナルはその問題では使用できません。 そして、なぜこのスレッドは閉じられているのですか？ それは最優先の問題であるべきです。

そして、なぜこのスレッドは閉じられているのですか？

@MasMedIm詳しく調べてみると、このバグは修正されていると信じており、修正されたバージョンもリリースされていることに気付くかもしれません。

@lheckerそれは非常に珍しいことです。 Azureコネクタは別のレイヤー（制御ではなく接続）にあるため、これとは何の関係もありません...しかし、それは関係なく興味深いものです。

あなた（または誰か）はv0.3.2142.0のストアバージョンを再チェックして、ローカルで構築されたものと比較できますか？

AltGr特殊文字が機能するバージョンは、ストアバージョンです。

AltGr（ ~#{[|`\^@]}¤€ ）は、フランス語キーボード、Windows 10バージョン1903ビルド18362.267、およびWindowsターミナルプレビュー0.3.2142.0で正常に動作します。

@ sba923私もフランス語のキーボードと同じWindowsバージョンを持っています。 動作しないAltGrの組み合わせは次のとおりです：＆〜＃{[| `\ ^€ù\
私の端末もストアからダウンロードされます。 ローカルで構築してみます。

私の状況を詳しく説明するために、AltGr + Keyの組み合わせの中には、実際には機能するものと機能しないものがあります。

動作しません：

| キー| AltGr +キー、予想：|
| ----- | ----------------------- |
| '2' | '@' |
| '3' | '£' |
| '4' | '$' |
| '7' | '{' |
| '8' | '[' |
| '9' | ']' |

作品：

| キー| AltGr +キー、予想：|
| ----- | ----------------------- |
| '0' | '}' |
| '´ '| '|' |
| '<' | '\' |
| '¨' | '〜' |
| 'e' | '€' |

注：「 ´」、「¨」はデッドキータイプです。

システム：Windows 1064ビットホーム1903ビルド10.0.18362.267
Windowsターミナル：プレビューv0.3.2142.0-ストアバージョン
キーボードレイアウト：デンマーク語。

@MasMedIm、@ sba923、@lhecker -ホーム私のようなあなたのWindowsのバージョンはありますか？
編集：私の質問を忘れてください。 私はそこで野生のガチョウの追跡を始めようとしてい@lheckerは退行を解決したようです！

@ DHowett-MSFT @ henrik-jensenet。 al .:回帰の原因を見つけました。 ¯\ _（ツ）_ /¯
...そしてそれは私たち全員をここで以前に気づいたためのたくさんのモロンにします。 😂

新しいprofiles.jsonには、タブ1-10にすばやくジャンプするためのCtrl+Alt+[0-9]種類のショートカットが含まれています。
これらのショートカットを設定ファイル（ Ctrl 、 ）から削除すると、リグレッションが修正されます。
€ AltGr Eのような特定の組み合わせは、残念ながらまだ機能していません。誰かがこれを修正するために必要な時間をとる必要があります。

古いWindowsAPIの動作方法により、 Ctrl Altショートカットと実際のAltGrキー押下を確実に区別することは困難になりますが、状況を何らかの方法で改善できるかどうかを確認します。

@ lhecker🥇👍
確認済み。 ジュビイ

€ AltGr Eのような特定の組み合わせは、残念ながらまだ機能していません。誰かがこれを修正するために必要な時間をとる必要があります。

AltGr E-> '€'は私のデンマーク語のキーボードレイアウトで機能します。 セットアップで再現できるかどうかを確認するために、ドイツ語のレイアウトを追加してみます。

弾丸を噛むだけではどうですか？ レガシー（DOS）アプリ用に古いCMD.EXEを保持し、将来のためだけに新しいターミナルを設計しますか？ 下位互換性が良くないというわけではありませんが、ネクタイを切る必要がある場合もあります...

@ lhecker🥇👍
確認済み。 ジュビイ

€ AltGr Eのような特定の組み合わせは、残念ながらまだ機能していません。誰かがこれを修正するために必要な時間をとる必要があります。

AltGr E-> '€'は私のデンマーク語のキーボードレイアウトで機能します。 セットアップで再現できるかどうかを確認するために、ドイツ語のレイアウトを追加してみます。

インストールされているドイツ語の〜Kezboard〜ups、キーボード:-) *、およびAltGr E-> '€'はこのセットアップで機能します。

編集：* 'z' / 'y'はドイツ語/デンマーク語のキーボードで交換されます。

新しいprofiles.jsonには、タブ1-10にすばやくジャンプするためのCtrl+Alt+[0-9]種類のショートカットが含まれています。

何らかの理由で、これらのショートカットは設定ファイルでalt + [0-9]であるため、問題は発生しませんでした

今、いくつかの質問が私に起こります：

• @lheckerたぶん、発見可能性/履歴の回帰について新しい問題を作成する必要があり、それにパッチソリューションを追加できますか？ 編集：すばらしい- @ lheckerがプルリクエストを行いました＃2235
• デフォルトの〜settings.json〜 profiles.jsonはどこで生成されるのだろうか。 これはリソースではないので、どこかにハードコーディングされていると思いますか？ 編集： CascadiaSettings.cppL369が見つかりました
• 代わりに、どの代替ショートカットを選択する必要がありますか。 たぶん@saadanerdetbareが彼のprofiles.json （0.3.2142.0より前のデフォルトでしたか？編集：そうです-＃2014）

@lhecker @ henrik-それは理にかなっているジェンセン。 ストアでリリースされた直後にインストールし、 profiles.jsonいくつかの変更を加えたため、カスタムでデフォルトではないために更新によってファイルが上書きされなかった場合、Ctrl + Altショートカットを取得できませんでした

@ DHowett-MSFT @ henrik-jensenet。 al .:回帰の原因を見つけました。 ¯_（ツ）_ /¯
...そしてそれは私たち全員をここで以前に気づいたためのたくさんのモロンにします。 😂

新しいprofiles.jsonには、タブ1-10にすばやくジャンプするためのCtrl+Alt+[0-9]種類のショートカットが含まれています。
これらのショートカットを設定ファイル（Ctrl）から削除すると、リグレッションが修正されます。
€ AltGrEのような特定の組み合わせは、残念ながらまだ機能していません。誰かがこれを修正するために必要な時間をかけなければなりません。

古いWindowsAPIの動作方法により、CtrlAltショートカットと実際のAltGrキー押下を確実に区別することは困難ですが、状況を何らかの方法で改善できるかどうかを確認します。

応答のタイ、確かにそれはCtrl + Alt + [0-9]設定でした

@saadanerdetbare 、ええ、それはあなたの設定からここで新しいものに変更されました＃2014 by @ zadjii-msft

新しいショートカットがフランス語キーボードのAltGr（ ~#{[|`\^@]} ）を壊してしまうことを確認しました。

一部の人がリグレッションを認識しなかった理由は、 profiles.jsonオーバーライドしない0.3アップグレードに関連しています。

注：このリリースより前にターミナルを以前にインストールしたことがある場合、これらのキーバインディングは、profiles.jsonを削除して再生成を許可した場合にのみ、デフォルトで表示されます。 元のprofiles.jsonを別の場所に保存して、カスタマイズをコピーするか、これらのキーバインディングを手動で追加することができます。 これは理想的なエクスペリエンスではないことを認識しており、これを改善するために取り組んでいます。

ctrl + alt + shift + _digit_を使用できますが、入力するのは簡単ではありません...

@ henrik-jensen＃2235を開きました。

@thorsig WindowsAPIランドスケープの状況についてはすでに
特に、たとえばLinux上のbash（将来Windowsで使用する可能性のあるほとんどのシェルと同様）は、生のキーコードを受信せず、エスケープシーケンスが挿入された通常のテキストを受信します。 端末がキーボードイベントから生成する必要のあるエスケープシーケンス。 Linuxシェルは生のキーコードを_処理しません_。 あなたの端末はそうします。
これを続行する前に、まずxtermとvt100（およびそれ以降）がどのように機能するかを理解する必要があります。
そしてところで：Linuxのキーコードもキーボードからのスキャンコードに対する単なる仮想（！= raw）抽象化です- keymaps.5参照してください。 唯一の違いは、WindowsではCtrl + AltがAltGrと同じであると以前に決定されていたということです。これは、AltGrキーがないキーボードもありますが、それでも何らかの方法でAltGrを押したいと思っていたためです。 これを決めた人は、最近60歳以上かもしれません。 これを変更することは簡単ではなく、わずかな利点しかありません（とにかく、実際にはAltGrキーの押下を検出できるため）。

新しいショートカットがフランス語キーボードのAltGr（ ~#{[|`\^@]} ）を壊してしまうことを確認しました。

一部の人がリグレッションを認識しなかった理由は、 profiles.jsonオーバーライドしない0.3アップグレードに関連しています。

注：このリリースより前にターミナルを以前にインストールしたことがある場合、これらのキーバインディングは、profiles.jsonを削除して再生成を許可した場合にのみ、デフォルトで表示されます。 元のprofiles.jsonを別の場所に保存して、カスタマイズをコピーするか、これらのキーバインディングを手動で追加することができます。 これは理想的なエクスペリエンスではないことを認識しており、これを改善するために取り組んでいます。

ctrl + alt + shift + _digit_を使用できますが、入力するのは簡単ではありません...

alt + _digit_を使用する方が簡単で、gnome-terminalのショートカットに似ています。
それは私のフランス語キーボードで動作します。

Alt + Digitを使用する場合は、これらのキーをコンソールアプリケーションに送信できないことに注意してください。

： tada：この問題は＃2235で解決され、 Windows Terminal Preview v0.3.2171.0として正常にリリースされました。：tada：

便利なリンク：

• リリースノート
• ストアのダウンロード

AltGr（ ~#{[|`\^@]}¤€ ）は、フランス語のキーボード、Windows 10バージョン1903ビルド18362.267、Windowsターミナルプレビュー0.3で正常に動作します。 2171 .0、およびタブ切り替えショートカットがCtrl+Alt+digit設定されています。

よくやった！

確認していただいてありがとうございます！

いいえ、どいたしまして！

0.3.2171.0修正が私のシステムで確認されました-デンマーク語キーボードWin10Home1903ビルド10.0.18362.267。
デフォルト設定を取得するためにprofiles.jsonを削除しました。現在、AltGrは新規インストールでも機能します（私は推測します）。
素晴らしい仕事@lheckerと他のすべての関係者。

こんにちは私はバージョン0.7でこの問題があると思います。

数字キーパッドまたはAltGr + Q（疑問符/スラッシュキーのないSamsungラップトップのブラジルのABTN2キーボード）を使用しても、キーボードでスラッシュキーを入力できません。

編集：AltGrキーを入力できません。

PSReadlineの古いバージョンを削除した後、すべてが機能するようになりました。

FWIW、添付のPowerShellスクリプトを作成して、システムにあるPSReadlineのバージョン/アクティブなバージョンを確認しました。

CheckPSReadLineStatus.zip

HTH

bepplerが報告したのと同じ問題を修正するには、次のようにします。

PSReadlineの古いバージョンを削除した後、すべてが機能するようになりました。

昇格されたPowerShellセッションから：

Install-Module -Name PowerShellGet -Force
Exit

昇格したcmdセッションから：
powershell -noprofile -command "Install-Module PSReadLine -Force -SkipPublisherCheck -AllowPrerelease"

この問題の状況はどうなっていますか？
リンクされた問題を見ると修正されているように見えますが、それでも機能しません。 イタリアのキーボードレイアウトで〜文字を印刷するために、私はAlt + 126を実行することに慣れていますが、これは端末のタイプによって動作が異なりますが、いずれの場合も〜文字を取得できません基になるシェル（Windowsターミナルに埋め込まれていないgit / cmd / powershell / wsl）で直接実行している間は、期待どおりに機能します。

これは、Windowsターミナルの最新バージョンで私に起こっています。執筆時点では次のとおりです。

Windows Terminal (Preview)
Version: 0.8.10091.0)

@ ilmax ＃3117でAlt + Numpad入力を壊しました。 ＃3117がマージされ、関連する問題が修正されたので、コードベースにテンキー入力を再導入する作業を行うことができます。
ただし、これはオプションの構成可能な動作にします。これは、ターミナルアプリのほとんどの潜在的なユーザーがこれ以上メリットを享受できないと確信しているためです。 したがって、アプリはデフォルトですべての可能なキーボード入力をシェルに送信する必要があります。これにより、より高度なvimなどのキーバインドを構成できます。
＃4192がマージされるとすぐに、これを実装するのはかなり簡単になるはずです。 ここにロジックを追加して、Altキー（およびAltキーのみ）がstatesに保持されているかどうかを確認する必要がありますが、vkeyは通常の数字キーではなくテンキーに由来します。 いつでもPRを提出してください！ 🙂

@lhecker迅速な対応に感謝します。見つけたすべての問題は解決されましたが、問題はまだ残っているため、この状態を知りたかっただけです。
これについてPRを思いつくかどうかはわかりませんが、これまでコードを見たことがなかったので、あなたの提案にもかかわらず、どこから始めればよいのか本当にわかりません。

git rebase -iのワークフローを修正する方法を知りたかっただけです。これは、notepad ++のようなものを開き、〜文字を入力してコピーし、ターミナルに貼り付ける必要があるためです。

ちょうど私が理解しているように：あなたは_alt + numpadシーケンス_についての質問でAltGrについてのスレッドにいますか？ これが、見つけたすべてのスレッドが閉じている理由である可能性があります。AltGrの問題が修正されています。

alt + numpad入力の問題を追跡する別の問題があると思います。

うん、あなたは正しい、混乱してすみません。 ＃657が正しいかもしれないと思います