업데이트 : Alt Gr 와 결합하면 모든 숫자에 동일한 일이 발생합니다.

알다시피, 이건 아마도 나에게 달려 있습니다. KeyDown 이벤트를받을 때 TermControl.cpp 어딘가에서 AltGR 콤보에 대해 vkey를 올바르게 얻지 못할 수 있습니다.

약간 관련이 없지만 gif @patriksvensson 에서 누른 키로 녹음하기 위해 어떤 소프트웨어를 사용

@watermelonpizza 저는 Carnac 을 사용하여 키 누름을 표시하고 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 하지만.
또한 눌러 진 가상 키는 예를 들어 일부 이미 변환 된 유니 코드 문자 대신 "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를 반환 함을 알 수 있습니다.

Btw, 수정 자 상태는 TermControl :: _ KeyDownHandler ()의 _GetPressedModifierKeys ()에 의해 획득됩니다. 부울 값 대신 수정 자 상태를 SendKeyEvent에 직접 전달하고 나중에 왼쪽 / 오른쪽 ctrl, 왼쪽 / 오른쪽 alt, 왼쪽 / 오른쪽 시프트를 눌렀는지 여부를 확인할 수 있습니다.

그리고 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 DWORD 수정자를 초기화하는 대신
AltGr + <(= |)도 작동합니다.

그러나 AltGr + Q는 실제로 작동하지 않는 것 같습니다. 기묘한.
AltGr + E (= €)도 작동하지 않습니다.

새로운 C # UWP를 설정하여 AltGr을 사용하는 동안의 키 시퀀스는 다음과 같습니다.

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
  
  
  • InputTest::TerminalInputModifierKeyTests#metadataSet3 ~ set10 포함
  
  

@lhecker 호기심으로 isAltGrPressed() 를 isAltPressed() && isCtrlPressed() 로 바꾸는 첫 번째 아이디어를 적용하고 다음 사항을 확인했습니다.

• @ 및 €를 포함한 CMD에서 작동하지만 PS 또는 WSL에서는 작동하지 않습니다.
• 실제로 통과하지 못하는 테스트를 수정하지 않습니다.
• 대신 영어 키보드의 경우 MouseInputTest::SgrModeTests#metadataSet20 를 중단합니다.

문제를 더 좁히지 못했지만 정보가 유용 할 것이라고 생각했습니다.

@MattKuhr 매우 흥미 롭습니다. @ 및 €는 실제로 PowerShell과 WSL 내에서 모두 작동합니다. 🤔
(단지 100 % 확실합니다- 이것은 현재 마스터 67f68eb에 대한

실제로 현재 마스터로 업데이트하고 다시 테스트했습니다. 이제 PS의 €를 제외하고 특수 문자가 작동합니다.

이전에 관찰 한 동작의 원인이 무엇인지 확실하지 않으며 정확히 동일한 코드 변경이 사용되었습니다. 여러 번 테스트했지만 그 동안에 설치된 일부 Windows 업데이트가 영향을 받았지만 테스트하는 동안 배포에 문제가있을 수 있다고 생각하기 시작했습니다.

다음은 현재 마스터에서 테스트 할 때 독일어 키보드가 설정된 화면 캡처입니다.

디버그 및 릴리스 (x64), Win 10.0.18362.116에서 테스트했습니다. 나는 또한 시스템 언어를 변경하려고 시도했지만 효과가 없었습니다. 이 경우에만 €가 올바르게 번역되지 않는다는 것이 약간 이상해 보입니다.

먼저 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 , 예상 €

일반 문자의 경우 Alt Gr은 시프트처럼 작동합니다. 다른 문자는 수정 자없이 값에 남습니다.

@ DHowett-MSFT 실제로합니다 😃

다른 키는 계속 작동합니다. 또한 이전에는 작은 3이 정상 3으로 작성되었지만 이제는 아래 스크린 샷에서 볼 수 있듯이 올바르게 나타납니다.

안녕하세요,

이것이 핀란드어 QWERTY 레이아웃에도 영향을 미치므로 @, |, {}, [], ~, \ 등과 같은 모든 AltGr 조합을 사용할 수 없게됩니다.

이들 모두는 WSL, cmd 및 powershell의 @lhecker 의 패치로 잘 작동하는 것 같습니다. 감사합니다 @lhecker !

안녕하세요, French Azerty 키보드 레이아웃에서도 작동합니다. 감사합니다 @lhecker

스위스 독일어 키보드에서 Alt Gr 조합에 문제가 있습니다 (예 : "Alt Gr + <"(백 슬래시이지만 결과는 "<")).

지나가는 사람이 무엇을 추적하고 있는지 더 명확하게 알 수 있도록이 문제의 제목을 업데이트했습니다.

@ zadjii-msft terminalInput.cpp에서 (?) AltGr 관련 주석을 찾았습니다.
따라서 나는 대체 ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
와...
if (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
거짓 반환;
}
... 그리고 작동합니다! 지금은. 😅

이 변경으로 인해 프랑스어 키보드에서 사용할 수있는 AltGr도 제공됩니다. 지금까지 CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (둘 다 VScode에서 작동해야하는 비공식 PSReadline 2.0.0beta4 포함)으로 테스트했습니다.

이 변경으로 인해 프랑스어 키보드에서 사용할 수있는 AltGr도 제공됩니다. 지금까지 CMD, Windows PowerShell 5.1, PowerShell Core 6.2.1 (둘 다 VScode에서 작동해야하는 비공식 PSReadline 2.0.0beta4 포함)으로 테스트했습니다.

내 PSReadline 버전을 확인하고 2.0.0에서 2.0.0-beta4로 업그레이드했는데 그게 트릭을했고, 이제 € 및 ³도 PS, 5.1 및 6.2.1 모두에서 올바르게 작동합니다. 😄

PSReadline과 관련된 것으로 보이는 다른 버그를 찾았지만 AltGr 또는 키보드 레이아웃과는 직접 관련이 없습니다. 아래에서 볼 수 있듯이 터미널에서 CTRL 2 는 " 및 CTRL 7 (GER 레이아웃, 미국에서는 CTRL / )에서 ^_

첫 번째 경우에는 PSReadline을 제거하는 것이 트릭을 수행하고 두 번째 경우에는 그렇지 않습니다. 다른 숫자와 특수 문자 키를 시도했지만 지금까지 찾을 수 있었던 유일한 두 인스턴스는이 두 개였습니다. 동작은 5.1과 6.2.1에서 동일합니다. PSReadline은 2.0.0beta4입니다.

이것에 대해 별도의 문제를 열어야합니까?

포르투갈어 (포르투갈) 키보드에서도 관련 문제가 있습니다.
예상 : Alt Gr + 2/3/4/7/8/9/0은 @ £ § {[]}, Alt Gr + e는 €를 출력해야합니다.

Windows 터미널 :
-PS Core : Alt Gr + digit가 PSReadline DigitFunction을 트리거합니다 (7 개의 출력 제외) ^ _
-PS Core : Alt Gr + €는 아무것도하지 않습니다.
-Windows Powershell : PS Core와 동일
-CMD : Alt Gr + digit는 숫자를 출력합니다. 단, 7 개 출력 ^ _
-CMD : Alt Gr + e 출력 E

내장 콘솔 :
PS Core : Alt Gr + 2/3/4/7/8/9/0 출력 @ £ § {[]}, Alt Gr + E는 아무 작업도하지 않습니다.
Windows PowerShell : PS Core와 동일
CMD-모든 작품

Windows 10 1903 18362.116
PS 코어 6.2
Windows 터미널 0.1.1431.0
PSReadline 2.0.0

"Alt Gr"키 조합이 작동하지 않을 때 시도 된 진정한 해결 방법은 Alt + NumPad 코드 를 사용하는 것입니다.

그러나 이것도 작동하지 않습니다!

657 "Alt + Numpad가 작동하지 않음"

나는 누구든지이 문제를 다루는 사람도이 밀접하게 관련된 문제를 다루도록 조언합니다.

아이슬란드 어 키보드에서도 이것을 확인할 수 있습니다. AltGr을 사용하여 다음을 작성합니다.
@ | € {[]} \ µ ~`^

참고 :이 문제는 거의 모든 Microsoft 명령 줄 기술에서 발생합니다. 이미 OpenSSH 에서 나타 났고 비슷한 문제가 PSReadline 에서

명령 줄을 시도 할 때마다 입력 문제가 항상 발생합니다. Home-End가 작동하지 않고 SSH를 통해 작동하지 않기 때문에 여전히 원격 세션에서 PowerShell을 사용할 수 없습니다.

어쨌든이 터미널 -SSH-PSReadline 삼각형은 저주를 받았습니다.

여기에서는 PT-BR 키보드 레이아웃을 사용하고 있습니다.

/ 를 받으려면 Alt Gr + Q

터미널에서 사용할 때 실행 취소 명령처럼 작동합니다. 내 마지막 명령 / 문자 / 단어를 다시 입력합니다.

안녕하세요.

AltGr 조합이 작동하지 않는 곳.

AltGr 조합이 작동하지 않는다는 뜻입니까?

먼저 Remove-Module PSReadline PowerShell에서 작동하기 시작합니까? (걱정하지 마십시오. 현재 세션에만 영향을 미칩니다.) 그렇다면 몇 가지 아이디어가 있습니다!

나에게 적합하지 않음 (프랑스어 AZERTY 레이아웃)

그래서 ..... 새로운 아이디어가 있습니까? 수정 때문에 ...

```c ++
if (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
거짓 반환;
}
...

나를 위해 일하지 않았다 <. <

편집하다:

컴퓨터에 정의 된 기본 키보드 언어를 감지 한 다음 rebind-stuff @microsoft 를 수행하는 것이 더 똑똑하지

@Hedrauta 코드 변경이 작동하지 않는 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 코드 변경이 작동하지 않는 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 대신 CtrlAlt를 사용하면 무엇을 얻을 수 있습니까?

@ renatop7 AltGr 대신 CtrlAlt를 사용하면 무엇을 얻을 수 있습니까?

같은 결과

터미널 외부, 즉 표준 CMD 또는 Windows Powershell 또는 Powershell Core에서? CtrlAlt는 항상 AltGr처럼 작동합니까?

터미널 외부, 즉 표준 CMD 또는 Windows Powershell 또는 Powershell Core에서? CtrlAlt는 항상 AltGr처럼 작동합니까?

예, 터미널 외부에서 완벽하게 작동합니다.
AltGr 또는 Ctrl + Alt와 함께 사용하면 예상 한 결과가 나타납니다.

15 분 전에 가져옴 : 전혀 작동하지 않음
글쎄, 마이크로 소프트는이 문제와 관련된 해결책도 가지고 있는가?

@Hedrauta 코드 변경이 작동하지 않는 xxx 값에 대한 일반 CMD에서 Ctrl+Alt+xxx 은 (는) 무엇을합니까? 내가 기억할 수있는 한, Ctrl+Alt 는 항상 AltGr 와 동일해야합니다 ...

음, 표준 독일어?. 여기에 어떻게 보이는지 화면이 있습니다. https://i.imgur.com/mvgHkxi.png
매크로를 통해 키를 입력 해 보겠습니다 .... 테스트

내 왼쪽 alt는 Alt가 아니라 Shift입니다 ...
시도한 결과
Ctrl + Q ^ Q
Ctrl + Alt + QQ
그냥 Q q
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://github.com/microsoft/terminal/blob/ce4c6d6124c258c676b4eeac61a709c1fb3da459/src/terminal/input/terminalInput.cpp#L392 -L396

이 실험적인 수정으로 :

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

이렇게하면 독일어 (또는 유사한) 키보드의 @{}[] 와 같은 문자를 포함하여 대부분의 키보드 언어에 대한 대부분의 키 조합이 수정됩니다.

추신 : 저는 어떤 방식이나 형태로든 Microsoft와 관련이 없으며 개인적으로 이러한 "#metoo"댓글이 너무 시끄 럽거나 비생산적이라고 생각하기 때문에이 글을 쓰고 있습니다. 🙂
PPS : 일부 사람들은 내가 PR을 직접 제출하지 않는 이유를 궁금해 할 것입니다. 자신을 인용하자면 : "내 변경 사항이 잘못된 것 같습니다. 모든 문자가 WM_CHAR 의해 처리되지 않는 이유가 있습니까?" 위의 수정 사항의 단점이 무엇인지, 제대로 수행하는 방법을 실제로 알지 못함을 의미합니다.

PPS : 일부 사람들은 내가 PR을 직접 제출하지 않는 이유를 궁금해 할 것입니다. 내 자신을 인용하자면 : "내 변경 사항이 잘못된 것 같습니다. WM_CHAR에 의해 모든 문자가 처리되지 않는 이유가있는 것 같습니다." 위의 수정 사항의 단점이 무엇인지, 제대로 수행하는 방법을 실제로 알지 못함을 의미합니다.

알 수있는 한 가지 방법은 PR을 제출하고 팀에서 수정하는 것입니다. 약간 과잉이지만 일이 더 빨리 움직일 것이라고 생각합니다.

@NatoBoram 😤👉 # 1436

예제 응용 프로그램 (예 : VtPipeTerm)을 사용할 때 alt-gr 키가 작동합니다.

@HBelusca VtPipeTerm은 새 UWP 터미널을 기반으로하지 않으므로이 문제가 발생하지 않습니다.
근본적인 문제에 대한 가능한 설명은 # 1436을 읽을 수 있습니다.

@lhecker Cascadia를 기반으로하지 않지만 동일한 기본 의사

감사합니다 @HBelusca

특수 키는 터미널 및 Windows 앱에서 수년 동안 작동했습니다. 2019 년에이 문제가 발생하는 이유는 무엇입니까? 터미널 프로그램의 입력 시스템을 완전히 다시 구현 했습니까? 그렇게해서 몇 년 전에 수정 된 버그를 다시 도입해야했기를 바랍니다. 이 문제는 코드 페이지, 언어 키보드 매핑 및 Windows 특정 키로 인해 Linux에서 일반적 이었지만이 중요한 버그는 스토어에서 사용 가능하고 모든 곳에서 공개되는 애플리케이션의 미리보기 버전에 있습니다.

@ifilgud이 미리 이유로 매장에서 사용할 수있는 미리보기 버전입니다. 이 문제는 분류되었으며 제출 된 PR도 있으므로 불만을 제기하기 위해이 문제에 대해 언급 할 필요가 없습니다.

@patriksvensson 나는 내가 주로 불평하고 있다는 것을 알고 있으며 그것은 "정중 한"것이 아니라 이와 같은 버그의 이유를 설명 할 기술적 이유를 요구하기도합니다. 거의 완성 된 버전 (미리보기)에서 수정해야 할 사소한 오류가있을 것으로 예상했지만 처음부터 작성하고 영어로만 테스트하지 않는 한 터미널의 진화에는 존재해서는 안되는 오류가 발생하지 않았습니다. 첫 번째 알파 버전에서는이를 감지하지 못함). 터미널을 열고 두 번째 명령으로 "cd \"를 쓰려고했지만 (첫 번째는 "dir") 작동하지 않았습니다. 소프트웨어 개발자로서 이것은 저에게 많은 영향을 미쳤습니다.

@lhecker 지금까지 실험적인 수정 사항을 적용한 후 너무 좋습니다. 감사합니다 !!

이것을 지적하고 이미 고친 모든 ppl에게 대단히 감사합니다. 🌷

MS Store 앱은 얼마나 자주 업데이트됩니까?
그렇다면 언제 스토어 앱에서 문제를 해결할 수 있을까요?

터미널로 작업하고 싶지만 독일어 키보드로는 altgr 없이는 { } 를 쓸 수 없습니다. 😅

노르웨이 보크 몰 (nb-NO) 키보드 레이아웃에서도 동일한 문제가 발생했습니다. [], {} 또는 $를 만들 수 없습니다. PowerShell은 기본적으로 이것 없이는 손상됩니다.
Windows 10 1903 18362.175에서 UWP / Microsoft Store 버전 0.2.1715.0 사용.

AltGr을 통한 hu_HU 레이아웃 : \ | & @ $ ; # <> {} [] 중괄호, 꺾쇠 괄호, 대괄호, 백 슬래시, 파이프, 달러 기호, 해시 표시, "at", "and", 세미콜론 ... 오 잠깐, 모든 줄 ?? :)

_ 여러분도이 문제를 다루고 있다고 언급하지 마시기 바랍니다 ._

지금 쯤이면이 문제가 광범위한 키 조합에 영향을 미치며 똑같이 광범위한 언어, Windows 버전, 키보드 등에 대해 똑같이 광범위한 예상치 못한 부작용을 초래할 수 있음을 모든 사람에게 분명히해야합니다.
댓글의 절반 이상이 #metoo 스타일이므로이 문제를 해결하는 데 전혀 도움이되지 않습니다.
_ 유용한 댓글을 덜 눈에 띄게 만듭니다 _.

업데이트 : Alt Gr 와 결합하면 모든 숫자에 동일한 일이 발생합니다.

이 gif 기록은 어떻게 했어?

@ Karl-WE 스레드에서 더 아래를보십시오.

@ DHowett-MSFT 하단의 메시지로이 스레드를 잠그는 것이 좋습니다.

이 문제가 발생하는 동안 터미널은 Powershell에서 매우 사용할 수 없습니다.
수정 될 때까지 자제 할 수없는 사람들을 위해 Windows 10 1903에 대한 해결 방법을 제시하고 싶습니다 ..

해결 방법 :
Windows 키 +를 사용하십시오.
특수 캐릭터 탭으로 이동 캐릭터 선택
터미널로 전환하고 문자를 삽입

잠금 해제 상태로두면 작동하지 않는 각 개별 키를보고 할 수있는 공간이 제공되어 작동하지 않는 각 개별 키에 대한 개별 _ 문제 _ 제출을 중단합니다. 나는 찢어졌다.

특수 문자가 예상대로 작동하지 않는 경우가 더 많을 수 있습니다. 덴마크어 키보드에서 @ 문자를 만들려면 Alt Gr + 2, Left Ctrl + Left Alt + 2 또는 Left Alt + Numpad 64의 세 가지 방법이 있습니다.
두 개의 첫 번째 옵션은보고 된 결과 OP를 제공합니다.
마지막 옵션은 powershell에서 수행합니다.
Onpres 왼쪽 Alt + Numpad 64 digit-argument: 64
Onrelease 왼쪽 Alt : 64 @ 문자
cmd에서
Onpres 왼쪽 Alt + Numpad 64 : 64
Onrelease 왼쪽 Alt : @ 결과 64@
wsl에서
Onpres 왼쪽 Alt + 숫자 키패드 64 : (arg: 64)
Onrelease 왼쪽 Alt : 64 @ 문자

@saadanerdetbare 좋은 포인트!

Alt + Numpad 문제는 새 터미널 (Cascadia)이 이러한 코드를 입력 할 때 적절한 이스케이프 코드를 셸로 전송한다는 사실에서 비롯된 것 같습니다. 그러나 동시에 응용 프로그램의 또 다른 부분은 Alt + Numpad 코드를 적절한 문자로 변환하고이를 쉘에 삽입하는 _also_이 경우를 처리하는 것입니다. 이로 인해 @ 문자가 64 번 반복되는 재미있는 부작용이 발생합니다 (셸에 \x1b6\x1b4@ 라는 바이트를 보냈기 때문에).

이 두 줄 사이에

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

이렇게하면 Cascadia가 이러한 이스케이프 코드를 셸로 보내는 것을 막을 수 있습니다. 나중에 문자 (예 : @)가 정상적으로 나타납니다.
또는 동일한 효과를 위해이 코드 블록을 제거 할 수 있습니다.

~ @saadanerdetbare AltGr 기능과 관련이없는 버그이기 때문에 문제를 자세히 설명하는 별도의 문제를 만들 수 있다면 정말
👉 # 1401
먼저 다른 문제를 검색해야했습니다. 🤦‍♂️

추신 : 알려지지 않은 다른 사람들에게 의존하는 대신 이러한 것들을 스스로 디버깅 할 수있는 커뮤니티의 준비가 증가하는 것을 보면 개인적으로 매우 자랑스러워 할 것입니다. 🙈🙂

@saadanerdetbare 는 새로운 문제를 제출하는

나는 여전히 미리보기 앱에서 이것을 경험하고 있으며, 벨기에 키보드를 가지고 있으며 @을 쓸 수 없습니다.

@solispauwels 다음 릴리스 까지 기다려야합니다 (또는 지금은 현재 마스터 브랜치를 직접 빌드).

안녕하세요, 저는 독일 키보드에서이 커밋을 테스트했으며 모든 것이 € 기호를 인쇄해야하는 altgr-E와 별도로 작동합니다. 솔직히 말해서 나는 종종 터미널에서 이것이 필요하지 않지만 어쨌든 언급 할 수 있다고 생각했습니다. µ에 대한 altgr-m과 같은 다른 것들은 작동합니다.

업데이트 : 나는 당신이 그것을 무시할 수 있다고 생각합니다. € 기호는 표준 powershell에서도 작동하지 않으므로 터미널의 결함이 아닌 것 같습니다.

모든 것이 프랑스어 키보드에서 작동하는 것 같습니다. AltGr+é"'(-è_çà)=$e 는 예상되는 ~#{[|`\^@]}¤€ 산출합니다.

프랑스어 키보드도 사용하고 있습니다 (하지만 벨기에에 있음). AltGr +에 문제가 있습니다.문자. 예를 들어 | # {} @는 작동하지 않습니다. Windows 10 v1903에서 Windows 스토어 0.2.1715.0의 최신 릴리스를 사용하고 있습니다.

@meuter 다음 릴리스 까지 기다려야합니다 (또는 지금은 현재 마스터 브랜치를 직접 빌드).

# 1436의 수정 사항은 Microsoft Store에서 제공되는 미리보기 버전에 아직 포함되어 있지 않습니다.

@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 Store 버전 11905.1001.4.0에서 버그에 직면 할 수 있습니다.
스토어는 다운로드 할 앱 (이미지 참조)을 "스택"하지만 자동 다운로드가 활성화되어 있고 네트워크가 통신 연결이 아닌 경우에도 앱을 다운로드하지 않습니다.

영향을받는 사용자는 Microsoft Store에서 "업데이트 확인"을 눌러야 고정 된 Store 앱을 얻고 보류중인 모든 앱 다운로드를 시작해야합니다.

새 버전의 터미널에서이 문제가 해결 될 것임을 확인합니다. 감사합니다.

이제이 문제가 해결되었음을 확인할 수 있습니다. 문제를 고정 해제 할 수 있습니다.

적어도 스페인어 키보드에서는 AltGr + e 인 유로 키를 제외하고 작동합니다. 나머지 조합은 제대로 작동합니다.

@ifilgud에서

적어도 스페인어 키보드에서는 AltGr + e 인 유로 키를 제외하고 작동합니다. 나머지 조합은 제대로 작동합니다.

"Belgian (Period)"AZERTY 키보드를 사용하여 2019-07-08의 최신 버전을 사용하여 Windows 10 1903 (18362.175)에서 테스트되었습니다.

검사 결과:

• 유로 (€) 통화 기호를 포함 하여 키보드에서 사용할 수있는 모든 조합은 Windows 터미널에서 기본으로 구성된 3 개의 콘솔 중 2 개 (PowerShell Core 및 'cmd'(Windows 명령 프롬프트))에서 작동합니다.
• "Windows PowerShell"에서만 유로 기호 (€) 가 작동
  
  
  
  • 그러나 그것은 PowerShell을 클래식 콘솔의 작업은 Windows 시작에서 직접 발사도하지 않습니다
  
  

Imo 이것은 Windows PowerShell과 관련된 새로운 문제이며 해당 콘솔을 호스팅하는 Windows 터미널에만 국한되지 않습니다.

@DeChrist 관찰을 확인합니다. 반면에 Ctrl-Alt + (Key) 누르기는 예상대로 작동하지 않습니다 (AltGr 대신이 조합을 사용하려는 경우).

여기에서 Windows Terminal Preview 버전 0.2.1831.0을 실행하는 Windows 10 빌드 18362.175에서 프랑스어 키보드를 사용하면 AltGr+E 가 다음 모든 셸에서 € 를 생성 합니다 .

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

남은 AltGr 문제가있는 사람이 _PowerShell_에서 실행중인 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을 참조

• 윈도우 10 1903
• Windows 터미널 0.2.1831.0
• PowerShell v7 (PSReadline 2.0.0-beta4 포함)
• 독일어 QWERTZ 키보드 레이아웃

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

Microsoft가 RDP 세션이 열려 있으면 AltGr + Q 작동이 중지되는 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에는 AltGr -...과 다른 결과를 생성하는 ctrl-alt -...를 사용하는 단축키가 있습니다.

제대로 할 수있는 기회는 단 한 번뿐입니다. 거의 40 년만의 첫 기회. 그 기회를 낭비하지 마십시오-Microsoft, 나는 당신을보고 있습니다 :)

@thorsig 아, Win32 입력 스택이 40 년 전에 설계되었을 때 우리가 주변에 있었다면. 안타깝게도 그렇게하지 않았으므로 키보드 입력을받는 두 가지 기본 방법이 있습니다.

• 수정 자없이 문자로 (따라서 터미널 파이프를 통해 보낼 ALT를 감지 할 수 없음) 또는 키 누르기 방향
• 수정 자와 방향이 있지만 실제로는 _ 물리적 키 위치 _의 표현 일뿐입니다.

운영 체제 수준 아래를보기 시작하면 스캔 코드는 "가능한 한 원시 입력"모드입니다. 그러나 텍스트 입력이 필요한 응용 프로그램으로 전달되기 전에 약간의 요리가 필요합니다. (추가하려면 편집 :) 터미널 응용 프로그램은 실제로 입력을 텍스트로 선호합니다. SSH 연결을 통해 스캔 코드를 보낼 수 없습니다! 가능하더라도 수신자는 번역을 수행하기 위해 키보드 레이아웃을 이해해야합니다. 아마도 헤드리스 머신에는 키보드 레이아웃이 없습니다. (/편집하다)

"그들이 눌렀 던 문자 그대로의 문자를 가져 와서 보내는 것"만큼 쉬웠다면 우리가 그렇게 할 것이라고 믿어야합니다. 우리는 미친 사람들이기 때문에 미친 솔루션을 설계하지 않습니다! :미소:

글쎄, 나는 그 당시 입력 스트림을 처리하는 방법에 대한 단서가 많지 않았지만 주변에있었습니다.

그러나 Linux는 기본적으로 원시 키 코드로 작동하므로 문제가되지 않습니다. 그러나 ssh 연결의 예는 ssh가 터미널 응용 프로그램에 의해 직접 실행되지 않기 때문에 결함이 있습니다. 셸에 도달하는 것을 담당하는 셸 내부 (또는 WSL과 같은 전체 OS 추상화)가 있습니다.

당신이 말한 것이 옳다면 Windows 용으로 작성된 모든 애플리케이션 (탐색기 위에서 실행)은 고유 한 키보드 처리를 구현해야합니다. 그렇지 않습니다. 업스트림과 다운 스트림을 처리하기 때문입니다.

나는 코드를보고 "SMH"에 대한 나의 몫을 가지고 있었다. 더 잘 할 수 있을까요? 시간이 주어진다면 아마. 내가 그것에 대해 나쁜 짓을 할 여유가 있습니까? 내가 직접 할 시간이 없다는 점을 감안할 때-아마 아닐 것입니다.

나는 여전히 언급 할 가치가 있다는 것을 알았다. 그것은있는 그대로 과도하게 설계되었고, 어느 시점에서 (아마도 더 빨리) 다운 스트림 문제를 일으킬 것이다.

글쎄, 나는 그 당시 입력 스트림을 처리하는 방법에 대한 단서가 많지 않았지만 주변에있었습니다.

그러나 Linux는 기본적으로 원시 키 코드로 작동하므로 문제가되지 않습니다. 그러나 ssh 연결의 예는 ssh가 터미널 응용 프로그램에 의해 직접 실행되지 않기 때문에 결함이 있습니다. 셸에 도달하는 것을 담당하는 셸 내부 (또는 WSL과 같은 전체 OS 추상화)가 있습니다.

WSL은 특정 종류의 번역을 수행하지 않습니다. conhost.exe 또는 Windows 터미널 (또는 XMing을 통해 그래픽 앱을 실행하는 경우 Gnome-terminal)은 pty로 전송하기위한 적절한 변환을 수행합니다. 그리고 쉘조차도 ... 대부분의 작업을 수행하는 쉘 자체가 아닙니다. 마스터 엔드의 터미널 드라이버 및 앱입니다 (다시 말하면 conhost.exe, Windows 터미널, 아마도 Cygwin 터미널, Linux 터미널 앱).

당신이 말한 것이 옳다면 Windows 용으로 작성된 모든 애플리케이션 (탐색기 위에서 실행)은 고유 한 키보드 처리를 구현해야합니다. 그렇지 않습니다. 업스트림과 다운 스트림을 처리하기 때문입니다.

대부분의 앱은 실제로 원시 키보드 입력을 신경 쓰지 않습니다. 이는 본질적으로 손실이 발생하는 방식으로 일부 Win32 라이브러리를 통해 처리됩니다. 원시 키보드 입력을 직접 사용하지 않습니다. 대부분의 앱은 물리적 레이아웃 입력을 정확히 신경 쓰는 게임 외에 캐릭터에만 신경을 씁니다. 어느 쪽이든 잘 작동합니다.

나는 코드를보고 "SMH"에 대한 나의 몫을 가지고 있었다. 더 잘 할 수 있을까요? 시간이 주어진다면 아마. 내가 그것에 대해 나쁜 짓을 할 여유가 있습니까? 내가 직접 할 시간이 없다는 점을 감안할 때-아마 아닐 것입니다.

나는 여전히 언급 할 가치가 있다는 것을 알았다. 그것은있는 그대로 과도하게 설계되었고, 어느 시점에서 (아마도 더 빨리) 다운 스트림 문제를 일으킬 것이다.

Linux 아날로그 인 Gnome-Terminal을 살펴보고 더 간단한 지 복잡한 지 확인하는 것이 좋습니다. X가 실제로 GDI32 또는 사용중인 윈도우 API보다 더 이상하기 때문에 더 복잡하다고 생각합니다.

0.2.1831.0 에서 회귀가
덴마크어 키보드에서 Windows Terminal Preview v0.3.2142.0 이 AltGr에 응답하지 않습니다.

Windows 터미널 (미리보기)
버전 : 0.3.2142.0
Microsoft Windows 1903 [버전 10.0.18362.267]

덴마크어 키보드와 v0.3.2142.0 Windows 빌드 10.0.18362.239가 있으며 언어 팩이없는 영어 운영 체제입니다. Alt Gr 특수 문자는 여기에서 작동하지만 Ctrl + Alt 시퀀스는 작동하지 않습니다.

덴마크어 키보드와 v0.3.2142.0 Windows 빌드 10.0.18362.239가 있습니다. 언어 팩이없는 영어 운영 체제입니다. Alt Gr 특수 문자는 여기에서 작동하지만 Ctrl + Alt 시퀀스는 작동하지 않습니다.

내 OS : Win10 Home 1903 빌드 10.0.18362.267
덴마크어 언어 팩이 기본값이지만 추가 미국 언어 팩이 설치된 덴마크어 운영 체제입니다.
흠-빌드 10.0.18362.267 vs 10.0.18362.239-거기에 단서가 있습니까? !!!

내 OS : Win10 Home 1903 빌드 10.0.18362.267
덴마크어 언어 팩이 기본값이지만 추가 미국 언어 팩이 설치된 덴마크어 운영 체제입니다.
흠-빌드 10.0.18362.267 vs 10.0.18362.239-거기에 단서가 있습니까? !!!

모든 세부 정보를 얻으려면 :
나는
Win 10 Enterprise en-US 1903 빌드 18362.239
덴마크어 키보드, 언어 팩 없음

미국 언어 팩을 기본으로 사용하는 계정으로 로그인을 시도했습니다. 터미널을 설치하고 덴마크어 키보드로 전환하여 선택한 언어 팩에 영향이 있는지 확인했지만 운이 없었습니다.

이것이 아는 사람에게 단서가 될지 모르지만 1809에서 1903으로 업그레이드하기 전에 온 스크린 키보드 ( c:\windows\system32\osk.exe )는 모든 conhost 앱, 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의 Store 버전을 다시 확인하고 로컬에서 빌드 한 버전과 비교할 수 있습니까?

AltGr 특수 문자가 작동하는 버전은 상점 버전입니다.

AltGr ( ~#{[|`\^@]}¤€ )는 프랑스어 키보드, Windows 10 버전 1903 빌드 18362.267 및 Windows Terminal Preview 0.3.2142.0에서 잘 작동합니다.

@ sba923 프랑스어 키보드와 동일한 Windows 버전이 있습니다. 작동하지 않는 AltGr 조합은 다음과 같습니다. & ~ # {[|`^ € ù \
내 단말기도 스토어에서 다운로드됩니다. 나는 그것을 지역에서 만들어 보려고 노력할 것입니다.

내 상황을 자세히 설명하기 위해 일부 AltGr + 키 조합은 실제로 작동하지만 일부는 작동하지 않습니다.

작동하지 않음 :

| 키 | AltGr + 키, 예상 됨 : |
| ----- | ----------------------- |
| '2'| '@'|
| '3'| '£'|
| '4'| '$'|
| '7'| '{'|
| '8'| '['|
| '9'| ']'|

공장:

| 키 | AltGr + 키, 예상 됨 : |
| ----- | ----------------------- |
| '0'| '}'|
| '´'| '|' |
| '<'| '\'|
| '¨'| '~'|
| 'e'| '€'|

참고 : '´', '¨'는 데드 키 유형입니다.

시스템 : Windows 10 64bit Home 1903 Build 10.0.18362.267
Windows 터미널 : 미리보기 v0.3.2142.0-스토어 버전
키보드 레이아웃 : 덴마크어.

@MasMedIm, @ sba923, @lhecker - 광산처럼 윈도우 버전 홈?
편집 : 내 질문은 잊어 버려. 나는 거기에서 야생 거위 추적을 시작하려고했지만 @lhecker 가 회귀를 해결 한 것 같습니다!

@ DHowett-MSFT @ henrik-jensen 외. al .: 회귀의 원인을 찾았습니다. ¯ \ _ (ツ) _ / ¯
... 그리고 그것은 여기에있는 우리 모두를 일찍 알아 차린 멍청이로 만듭니다. 😂

새로운 profiles.json 에는 탭 1-10으로 빠르게 이동할 수있는 Ctrl+Alt+[0-9] 종류의 바로 가기가 포함되어 있습니다.
설정 파일 ( Ctrl , )에서 이러한 바로 가기를 제거하면 회귀가 수정됩니다.
€ 대한 AltGr E 와 같은 특정 조합은 슬프게도 아직 작동하지 않았으며 누군가이 문제를 해결하는 데 필요한 시간이 필요합니다.

이전 Windows API가 작동하는 방식으로 인해 Ctrl Alt 단축키와 실제 AltGr 키 누르기를 안정적으로 구별하기가 어려울 수 있지만 상황이 어떻게 개선 될 수 있는지 확인하겠습니다.

@lhecker 🥇 👍
확인했습니다. Jubii

€ 대한 AltGr E와 같은 특정 조합은 슬프게도 아직 작동하지 않았으며 누군가이 문제를 해결하는 데 필요한 시간이 필요합니다.

AltGr E-> '€'가 덴마크어 키보드 레이아웃에서 작동합니다. 내 설정에서 재현 가능한지 확인하기 위해 독일어 레이아웃을 추가해 보겠습니다.

총알 만 물어 뜯는 건 어때? 레거시 (DOS) 앱을 위해 이전 CMD.EXE를 유지하고 미래를 위해 새 터미널을 디자인 하시겠습니까? 이전 버전과의 호환성이 그다지 좋지는 않지만 가끔은 관계를 끊어야합니다.

@lhecker 🥇 👍
확인했습니다. Jubii

€ 대한 AltGr E와 같은 특정 조합은 슬프게도 아직 작동하지 않았으며 누군가이 문제를 해결하는 데 필요한 시간이 필요합니다.

AltGr E-> '€'가 덴마크어 키보드 레이아웃에서 작동합니다. 내 설정에서 재현 가능한지 확인하기 위해 독일어 레이아웃을 추가해 보겠습니다.

설치된 독일어 ~ Kezboard ~ ups, Keyboard :-) * 및 AltGr E-> '€'가이 설정에서 작동합니다.

편집 : * 'z'/ 'y'는 독일어 / 덴마크어 키보드에서 바뀝니다.

새로운 profiles.json 에는 탭 1-10으로 빠르게 이동할 수있는 Ctrl+Alt+[0-9] 종류의 바로 가기가 포함되어 있습니다.

어떤 이유로이 단축키는 설정 파일에서 alt + [0-9]이므로 문제가 없었습니다.

이제 몇 가지 질문이 생깁니다.

• @lhecker 아마도 우리는 발견 가능성 / 이력에 대한 회귀에 대한 새로운 문제를 만들어야하고 패치 솔루션을 추가 할 수 있습니까? 편집 : 훌륭합니다- @lhecker 가 풀 요청을했습니다 # 2235
• 기본 ~ settings.json ~ profiles.json 이 생성되는 위치가 궁금합니다. 리소스가 아니므로 어딘가에 하드 코딩되어 있다고 가정합니까? 편집 : 그것을 발견 CascadiaSettings.cpp L369
• 대신 선택해야하는 대체 단축키. 아마도 @saadanerdetbare 가 그의 ~ settings.json ~ profiles.json (0.3.2142.0 이전의 기본값 이었습니까? 편집 : 그렇게 보입니다-# 2014)

@lhecker @ henrik-jensen이 의미가 있습니다. 스토어에서 출시 된 직후에 설치했고 profiles.json 를 약간 변경했습니다. 따라서 업데이트가 사용자 지정 파일이고 기본값이 아니기 때문에 파일을 덮어 쓰지 않았다면 Ctrl + Alt 바로 가기를 얻지 못했습니다.

@ DHowett-MSFT @ henrik-jensen 외. al .: 회귀의 원인을 찾았습니다. ¯_ (ツ) _ / ¯
... 그리고 그것은 여기에있는 우리 모두를 일찍 알아 차린 멍청이로 만듭니다. 😂

새로운 profiles.json 에는 탭 1-10으로 빠르게 이동할 수있는 Ctrl+Alt+[0-9] 종류의 바로 가기가 포함되어 있습니다.
설정 파일 (Ctrl)에서 이러한 바로 가기를 제거하면 회귀가 수정됩니다.
€ 대한 AltGrE와 같은 특정 조합은 슬프게도 아직 작동하지 않았으며 누군가이 문제를 해결하는 데 필요한 시간이 필요합니다.

이전 Windows API가 작동하는 방식으로 인해 CtrlAlt 단축키와 실제 AltGr 키 누르기를 안정적으로 구별하기가 어려울 수 있지만 상황이 어떻게 개선 될 수 있는지 확인하겠습니다.

응답을 위해 Ty, 실제로는 Ctrl + Alt + [0-9] 설정이었습니다.

@saadanerdetbare , 예, 설정에서 새 설정으로 변경되었습니다 # 2014 by @ zadjii-msft

새 단축키로 인해 프랑스어 키보드에서 AltGr ( ~#{[|`\^@]} )가 중단되는지 확인합니다.

우리 중 일부가 회귀를 보지 못한 이유는 Windows Terminal Preview v0.3 릴리스에 문서화 된 기존 profiles.json 재정의하지 않는 0.3 업그레이드와 관련이 있습니다.

참고 :이 릴리스 이전에 터미널을 이전에 설치 한 경우 이러한 키 바인딩은 기본적으로 profiles.json을 삭제하고 재생성을 허용 한 후에 만 ​​나타납니다. 원래 profiles.json을 다른 곳에 저장하고 사용자 정의를 복사하거나 이러한 키 바인딩을 수동으로 추가 할 수 있습니다. 이것이 이상적인 경험이 아니라는 것을 알고 있으며이를 개선하기 위해 노력하고 있습니다.

ctrl + alt + shift + _digit_를 사용할 수 있지만 입력하기는 쉽지 않습니다.

@ henrik-jensen # 2235를 열었습니다.

@thorsig Windows API 환경의 상황이 무엇인지 이미 들었습니다.
특히 예를 들어 Linux의 bash (향후 Windows에서 사용하려는 대부분의 셸과 마찬가지로)는 원시 키 코드를받지 않고 _ 오히려 이스케이프 시퀀스가 ​​포함 된 일반 텍스트를 수신합니다. 터미널이 키보드 이벤트에서 생성해야하는 이스케이프 시퀀스입니다. Linux 쉘은 원시 키 코드를 처리하지 _ 않습니다 _. 당신의 터미널이 그렇습니다.
계속하기 전에 먼저 xterm 및 vt100 이상이 작동하는 방식을 이해해야합니다.
그리고 btw : Linux의 키 코드는 키보드의 스캔 코드에 대한 가상 (! = raw) 추상화입니다. keymaps.5 . 유일한 차이점은 Windows에서 Ctrl + Alt가 AltGr과 동일하다는 것이 오래 전에 결정되었다는 것입니다. AltGr 키가없는 일부 키보드는 여전히 AltGr을 누를 수 있기를 원했기 때문입니다. 이것을 결정한 사람들은 요즘 60 세 이상일 것입니다. 이를 변경하는 것은 사소한 일이 아니며 별다른 이점 만 있습니다 (실제로 이미 AltGr 키 누름을 감지 할 수 있기 때문에).

새 단축키로 인해 프랑스어 키보드에서 AltGr ( ~#{[|`\^@]} )가 중단되는지 확인합니다.

우리 중 일부가 회귀를 보지 못한 이유는 Windows Terminal Preview v0.3 릴리스에 문서화 된 기존 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 Terminal Preview 0.3에서 잘 작동합니다. 2171 .0 및 탭 전환 바로 가기가 Ctrl+Alt+digit .

잘 했어!

확인 감사합니다!

당신은 매우 환영합니다!

내 시스템에 대한 0.3.2171.0 수정 확인-덴마크어 키보드 Win10 Home 1903 빌드 10.0.18362.267.
기본 설정을 얻기 위해 profiles.json 를 삭제했으며 이제 AltGr도 새 설치에서도 작동합니다 (가정합니다).
@lhecker 와 관련된 모든 사람들이

안녕하세요 버전 0.7 에서이 문제가 있다고 생각합니다.

숫자 키패드 ou AltGr + Q (물음표 / 슬래시 키가없는 삼성 노트북의 브라질 ABTN2 키보드)를 사용하여 키보드에 슬래시 키를 입력 할 수 없습니다.

편집 : AltGr 키를 입력 할 수 없습니다.

이전 버전의 PSReadline을 제거한 후 eveything이 작동합니다.

FWIW, 내 시스템에있는 PSReadline 버전 / 활성 버전을 확인하기 위해 연결된 PowerShell 스크립트를 작성했습니다.

CheckPSReadLineStatus.zip

HTH

beppler가보고 한 것과 동일한 문제를 해결하려면 다음을 수행하십시오.

이전 버전의 PSReadline을 제거한 후 eveything이 작동합니다.

상승 된 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에 대한 워크 플로를 수정하는 방법을 알고 싶었습니다.

이해합니다. AltGr에 대한 스레드에 _alt + numpad sequence_에 대한 질문이 있습니까? 이것이 당신이 찾은 모든 쓰레드가 닫힌 이유 일 수 있습니다 : AltGr 문제가 수정되었습니다.

alt + numpad 입력 문제를 추적하는 별도의 문제가 있다고 생각합니다.

네, 맞아요. 혼란스러워서 미안 해요. # 657이 맞는 것 같아요