Обновление: то же самое происходит со всеми цифрами в сочетании с Alt Gr .

Знаешь, это, наверное, на мне. Вероятно, мы неправильно получаем vkey для комбинаций AltGR где-нибудь в TermControl.cpp, когда получаем событие KeyDown.

Вроде не связано, но какое программное обеспечение вы использовали, чтобы получить запись с клавишами, которые вы нажимали в гифке @patriksvensson ?

@watermelonpizza Я использовал Carnac для отображения нажатия клавиш и ScreenToGif для захвата окна.

О, карнак, огромное спасибо! Я добавлю это в свой список вкусностей :)

Я думаю, что это дубликат № 487.

Упс, похоже, что левая рука не знает, что делает правая, и я только что создал круговую повторяющуюся ссылку.

Можно подтвердить эту проблему в Windows версии 10.0.18362.30 с венгерской раскладкой клавиатуры. Поведение различается в зависимости от того, какую консоль я использую:

• cmd: он просто записывает символ, но в верхнем регистре
• powershell: вообще ничего не делает
• git bash: ничего не записывает, но воспроизводит звуковой сигнал по умолчанию

@ zadjii-msft Я нашел ваш (?) комментарий по AltGr в terminalInput.cpp .
На моей немецкой клавиатуре состояние клавиши управления - LEFT_CTRL_PRESSED | LEFT_ALT_PRESSED вместо, казалось бы, ожидаемого LEFT_CTRL_PRESSED | RIGHT_ALT_PRESSED .
Кроме того, нажатая виртуальная клавиша представляет собой, например, «Q» вместо уже преобразованного символа Unicode.

Таким образом я заменил ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
с участием...

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

... и это работает! Теперь. 😅 Он делегирует обработку WM_CHAR / _CharacterHandler, который, по мнению Google, более надежен для обработки AltGr. (?) (Я еще не очень знаком с программированием под 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 здесь никогда не определяется правильно, что приводит к тому, что keyEvent.IsAltGrPressed в TerminalInput :: HandleKey возвращает false.

Кстати, состояние модификаторов получает _GetPressedModifierKeys () в TermControl :: _ KeyDownHandler (). вместо логического значения вы можете передать состояние модификаторов непосредственно в SendKeyEvent и определить, будут ли позже нажиматься левый / правый Ctrl, левый / правый alt, сдвиг влево / вправо.

И в VirtualKey уже определены следующие параметры, которые можно использовать в TermControl :: _ GetPressedModifierKeys ()

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

Ах, хороший улов @sagood!
К сожалению, исправления этой проблемы, насколько я понимаю, недостаточно ...
TerminalInput::HandleKey очевидно предполагает, что при нажатии AltGr ОС уже «предварительно перевела UnicodeChar в правильное альтернативное значение», что не относится, например, к AltGr + Q (= @) на немецкой клавиатуре.
Это означает, что текущая логика вокруг IsAltGrPressed() уже в некотором роде ошибочна.

@lhecker Я попытался использовать RIGHT_ALT_PRESSED вместо инициализации модификаторов DWORD. Я тестировал AltGr + '+' (= ~), он будет правильно отображаться в консоли.
AltGr + <(= |) также работает.

Но AltGr + Q действительно не работает. странно.
AltGr + E (= €) тоже не работает.

Создавая новую UWP на C #, я заметил, что последовательность клавиш при использовании AltGr выглядит следующим образом:

Menu
Control
Q

(возьмем для примера AltGr + Q)

Дальнейшая отладка показывает, что если вы заставляете программу запускать первую ветвь условия TerminalInput :: HandleKey из terminalInput.cpp, как показано ниже,

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, которые были установлены за это время, оказали влияние.

Это снимок экрана с немецкой клавиатурой, установленной при тестировании на текущем мастере:

Я тестировал его как на Debug, так и на Release (x64), Win 10.0.18362.116. Я также пытался изменить системный язык, но это не помогло. Кажется немного странным, что только в этом конкретном случае € переводится неправильно ..

Скажите, а в PowerShell он начинает работать, если вы сначала Remove-Module PSReadline ? (Не волнуйтесь: это повлияет только на ваш текущий сеанс.) Если так, у нас есть несколько идей!

@ 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 работает как shift. Любой другой символ остается в значении без модификатора.

@ DHowett-MSFT Это действительно так 😃

Остальные клавиши продолжают работать. Кроме того, раньше крошечный 3 был записан как обычный 3, теперь он отображается правильно, как вы можете видеть на скриншоте ниже.

Привет,

Это также влияет на раскладку QWERTY в Финляндии, делая все комбинации AltGr, такие как @, |, {}, [], ~ \ и т. Д., Непригодными для использования.

Кажется, все они отлично работают с патчем от @lhecker в WSL, cmd и powershell. Спасибо @lhecker !

Здравствуйте, это работает и для французской раскладки клавиатуры Azerty. Спасибо @lhecker

Возникла проблема с комбинациями Alt Gr, например «Alt Gr + <» (обратная косая черта, но в результате получается «<») на швейцарской немецкой клавиатуре.

Я обновил название этой проблемы, чтобы прохожие могли понять, что она отслеживает.

@ zadjii-msft Я нашел ваш (?) комментарий, связанный с AltGr, в terminalInput.cpp.
Таким образом я заменил ...
https://github.com/microsoft/Terminal/blob/660d31ac522186e615ec243de2a434c273464828/src/terminal/input/terminalInput.cpp#L415 -L419
с участием...
если (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
вернуть ложь;
}
... и это работает! Теперь. 😅

Это изменение также дает мне возможность использовать 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, и это помогло, теперь € и ³ также правильно работают в 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 + цифра запускает функцию PSReadline DigitFunction, кроме 7 выходов ^ _
-PS Core: Alt Gr + € ничего не делает
-Windows Powershell: то же, что и PS Core
-CMD: Alt Gr + цифра выводит цифру, кроме 7 выводит ^ _
-CMD: Alt Gr + e выводит E

Встроенная консоль:
PS Core: Alt Gr + 2/3/4/7/8/9/0 output @ £ § {[]}, Alt Gr + E ничего не делает
Windows PowerShell: то же, что и PS Core
CMD - Все работает

Windows 10 1903 18362.116
PS Core 6.2
Терминал Windows 0.1.1431.0
PSReadline 2.0.0

Испытанный и верный обходной путь, когда комбинации клавиш «Alt Gr» не работают, - использовать код Alt + NumPad .

Но это тоже не работает!

657 «Alt + Numpad не работает»

Я бы посоветовал, чтобы тот, кто обращается к этому, также обращался к этому тесно связанному.

Я могу проверить это и на исландской клавиатуре. Мы используем AltGr, чтобы написать это:
@ | € {[]} \ µ ~ `^

Небольшое примечание: эта проблема возникает практически во всех технологиях командной строки Microsoft. Это возникло уже в OpenSSH , аналогичная проблема возникла в PSReadline , и здесь снова, где ни одна из комбинаций AltGr не работает.

Каждый раз, когда я пытаюсь выполнить что-то из командной строки, всегда возникают проблемы с вводом. Я все еще не могу использовать PowerShell в удаленных сеансах, потому что Home-End не работает, и они все еще не работают через SSH.

Как-то проклят этот треугольник терминал-SSH-PSReadline.

Здесь я использую раскладку клавиатуры PT-BR.

Чтобы получить / я использую Alt Gr + Q

При использовании в Терминале он работает как команда отмены. Просто введите мою последнюю команду / букву / слово

@MathiasMagnus

где ни одна из комбинаций AltGr не работает.

Вы хотите сказать, что ни одна из комбинаций AltGr не работает?

Скажите, а в PowerShell он начинает работать, если вы сначала Remove-Module PSReadline ? (Не волнуйтесь: это повлияет только на ваш текущий сеанс.) Если так, у нас есть несколько идей!

У меня не работает (французская раскладка AZERTY)

так ..... какие-нибудь новые идеи? потому что исправление ...

`` c ++
если (keyEvent.IsAltPressed () && keyEvent.IsCtrlPressed ())
{
вернуть ложь;
}
...

у меня не сработало <. <

Редактировать:

Разве не разумнее определить основной язык клавиатуры, который определен на машине, а затем выполнить команду rebind-stuff @microsoft ?

@Hedrauta странно, что изменение кода не работает для вас. Какую раскладку клавиатуры вы используете? Что Ctrl+Alt+xxx делает для вас в обычном CMD для значений xxx , которые используются в сочетании с AltGr? Насколько я помню, 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 странно, что изменение кода не работает для вас. Какую раскладку клавиатуры вы используете? Что Ctrl+Alt+xxx делает для вас в обычном CMD для значений xxx , которые используются в сочетании с AltGr? Насколько я помню, 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 что вы получаете с CtrlAlt вместо AltGr?

@ renatop7 что вы получаете с CtrlAlt вместо AltGr?

Тот же результат

А вне Терминала, т.е. в стандартном CMD или Windows Powershell или Powershell Core? CtrlAlt всегда ведет себя как AltGr?

А вне Терминала, т.е. в стандартном CMD или Windows Powershell или Powershell Core? CtrlAlt всегда ведет себя как AltGr?

Да, вне Терминала работает отлично.
Используя с AltGr или Ctrl + Alt, я получаю ожидаемый результат.

получен 15 минут назад: вообще не работает
хорошо, Microsoft вообще работает над решением, связанным с этой проблемой?

@Hedrauta странно, что изменение кода не работает для вас. Какую раскладку клавиатуры вы используете? Что Ctrl+Alt+xxx делает для вас в обычном CMD для значений xxx , которые используются в сочетании с AltGr? Насколько я помню, Ctrl+Alt всегда должно быть эквивалентно AltGr ...

Гм, стандартный немецкий ?. вот скриншот того, как это выглядит: https://i.imgur.com/mvgHkxi.png
я попробую ввести ключ через макрос .... тестирование

у меня левый Alt - Shift, а не Alt ...
попробовал Результат
Ctrl + Q ^ Q
CTRL + Alt + QQ
просто Q q
Alt + QQ

Попробую подарить это, обновив комментарий тогда
Изменить: пытаясь подарить его, я понял, что моя Alt-Key распознается неправильно .... кто-нибудь знает, где определены виртуальные клавиши? тоже буду разбираться в этом;) но я не настолько опытен в C ++ или .... любом кодировании;)

Только для меня, как новичка в cpp, я проверил несколько файлов и нашел
C: \ Program Files (x86) \ Windows Kits \ 10 \ Include \ 10.0.17763.0 \ um \ WinUser.h
Итак .... для немецких раскладок VK_Menu не существует, верно? у нас просто есть VK_LMENU, верно?
я попробую внести некоторые изменения и проведу небольшое тестирование ... позже отредактирую результаты
Изменить 1: Сборка занимает много времени, как будто я перестраиваю всю свою систему oO
Изменить 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;
}

Это должно исправить большинство комбинаций клавиш для большинства языков клавиатуры, включая, например, символы типа @{}[] на немецкой (или аналогичной) клавиатуре.

PS: Я никоим образом не связан с 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 году? Вы полностью переработали систему ввода для терминальной программы? Я надеюсь, что это было необходимо сделать и заново представить ошибки, которые были исправлены много лет назад: s. Эта проблема была типичной для Linux из-за кодовых страниц, языковых раскладок клавиатуры и клавиш для Windows, но эта критическая ошибка есть в предварительной версии приложения, которая доступна в магазине и публикуется повсюду.

@ifilgud Это предварительная версия доступна в магазине по причинам предварительного просмотра. Эта проблема была упорядочена, и для нее также есть представленный PR, поэтому не нужно комментировать эту проблему, чтобы пожаловаться.

@patriksvensson Я знаю, что в основном жаловался, и это не "вежливо", но я также спрашивал техническую причину, чтобы объяснить причину такой ошибки. Я ожидал, что некоторые незначительные ошибки будут исправлены в почти законченной версии (превью), но не той, которая не должна была существовать в эволюции терминала, если она не написана с нуля и не проверена только на английском языке (я думаю, это причина не обнаруживать это в первой альфа-версии). Я открыл терминал и попытался ввести «cd \» в качестве второй команды (первая была «dir»), но это просто не сработало. На меня как на разработчика ПО это сильно повлияло.

@lhecker, пока все хорошо, после применения экспериментального исправления. Большое спасибо!!

Большое спасибо всем, кто указал на это и уже исправил это. 🌷

Как часто будет обновляться приложение MS Store?
Итак, когда мы можем ожидать, что что-то исправят в приложении магазинов?

Хотелось бы работать с терминалом, но с немецкой клавиатурой вы даже не можете написать { } без altgr. 😅

Та же проблема возникает и с раскладкой клавиатуры на норвежском букмоле (nb-NO). Невозможно создать [], {} или $. Без них PowerShell практически не работает.
Использование UWP / Microsoft Store версии 0.2.1715.0 в Windows 10 1903 18362.175.

Макет hu_HU через AltGr: \ | & @ $ ; # <> {} [] Я имею в виду, как часто я открываю фигурные скобки, угловые или квадратные скобки, обратную косую черту, вертикальную черту, знак доллара, знак решетки, "в", "и", точку с запятой ... о подожди, каждая строчка ?? :)

_Я прошу всех воздержаться от комментариев, что они тоже занимаются этой проблемой. _

К настоящему времени всем должно быть ясно, что эта проблема затрагивает большое количество комбинаций клавиш и может привести к столь же широкому количеству неожиданных побочных эффектов для столь же широкого количества языков, версий Windows, клавиатур и т. Д.
Более половины комментариев имеют стиль #metoo, что совсем не помогает решить эту проблему и
_только делает полезные комментарии менее заметными_.

Обновление: то же самое происходит со всеми цифрами в сочетании с Alt Gr .

как ты сделал эту гифку?

@ Karl-WE Посмотрите дальше в ветке.

@ DHowett-MSFT Может быть хорошей идеей заблокировать эту ветку с сообщением внизу

Хотя терминал очень непригоден для Powershell, пока эта проблема жива
Я хотел бы предложить обходной путь для Windows 10 1903 для тех, кто не может удержаться, пока не будет исправлен.

Обходной путь:
используйте клавишу Windows +.
перейдите на вкладку специальных символов выберите своего персонажа
переключитесь на Терминал и вставьте символ

Если оставить его разблокированным, у людей будет возможность сообщить о каждом отдельном неработающем ключе, чтобы они перестали записывать отдельные _выпуски_ по каждому отдельному неработающему ключу. Я разрываюсь.

Могут быть и другие случаи, когда специальные символы не работают должным образом. Если я хочу создать символ @ на датской клавиатуре, есть 3 способа сделать это: Alt Gr + 2, Left Ctrl + Left Alt + 2 или Left 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
При отпускании Left Alt: @ приводит к 64@
В WSL
Onpres Left Alt + Numpad 64: (arg: 64)
Onrelease Left Alt: 64 символа @

Хороший момент @saadanerdetbare!

Ваша проблема с Alt + Numpad, похоже, связана с тем, что новый Терминал (Cascadia) отправляет соответствующие escape-коды в оболочку, когда вы вводите эти коды. Но одновременно с этим другая часть приложения _также_ обрабатывает этот случай, переводя код Alt + Numpad в соответствующий символ и вставляя его в оболочку. Это приводит к забавному побочному эффекту, когда ваш символ @ повторяется 64 раза (из-за того, что в оболочку были отправлены следующие байты: \x1b6\x1b4@ ).

Вы можете попробовать это, добавив следующий дополнительный код между этими двумя строками :

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

Это не позволит Cascadia посылать эти escape-коды в оболочку. После этого ваши символы (например, @) будут отображаться как обычно.
В качестве альтернативы вы можете удалить этот блок кода для того же эффекта.

~ @saadanerdetbare Было бы
👉 # 1401
Надо было сначала поискать другие проблемы. 🤦‍♂️

PS: Я должен сказать, что, видя возросшую готовность сообщества отлаживать эти вещи самостоятельно, вместо того, чтобы полагаться на неизвестных других, я лично очень горд. 🙈🙂

@saadanerdetbare подождите, пока не заполните новый выпуск, это номер 1401: smile:

Я все еще испытываю это в приложении для предварительного просмотра, у меня есть бельгийская клавиатура, невозможно написать @

@solispauwels вам придется подождать до следующего выпуска (или пока самостоятельно создайте текущую главную ветку).

Привет, я только что протестировал этот коммит на немецкой клавиатуре, и все работает, кроме altgr-E, который должен печатать символ €. Честно говоря, мне это не нужно часто в терминале, но я подумал, что все равно могу упомянуть об этом. Другие вроде altgr-m вместо µ работают.

Обновление: я думаю, вы можете игнорировать это, символ € также не работает в стандартной оболочке PowerShell, поэтому, похоже, это не ошибка терминала, нужно было проверить это раньше.

Кажется, здесь все работает на французской клавиатуре: AltGr+é"'(-è_çà)=$e дает ожидаемый результат ~#{[|`\^@]}¤€

Я также использую французскую клавиатуру (но я в Бельгии), и у меня проблемы с AltGr +символы. | # {} @ например не работают. Я использую последнюю версию из магазина Windows 0.2.1715.0 в Windows 10 v1903.

@meuter вам придется подождать до следующего выпуска (или пока самостоятельно создайте текущую главную ветку).

Исправление от # 1436 еще не включено в предварительную версию, доступную в Microsoft Store.

@antoineco @ sba923 спасибо, вот что я понял. Я только что клонировал репо. Как только мой vs2017 завершит обновление, я собираюсь пересобрать его из исходников :-)

Спасибо всем за такую ​​усердную работу и заполнение наших почтовых ящиков отчетами. Особая благодарность отправку исправления! Мы только что отправили его в магазин с сервисным выпуском v0.2.1831.0. Для его обработки магазином может потребоваться некоторое время.

Мы только что отправили его в магазин

Итак, исходя из моего опыта публикации приложений в Windows Store, это должно занять от 3 дней до 3 недель 😉

Мы только что отправили его в магазин

Итак, исходя из моего опыта публикации приложений в Windows Store, это должно занять от 3 дней до 3 недель 😉

Казалось бы, меньше 6 часов. 😋

В любом случае, на моей шведской клавиатуре теперь все в порядке. 👍

Теперь работает с немецкой клавиатурой 👍

Работает с французской клавиатурой версии 0.2.1831.0! благодаря

Работает с французской клавиатурой версии 0.2.1831.0! благодаря

Подтверждено!

Прекрасная работа!

@ DHowett-MSFT Версия 0.2.1831.0, кажется, включает это исправление, но не другие исправления ошибок, такие как шрифты Powerline или копирование / вставка клавиш, это нормально?

Я подтверждаю, что Alt-Gr работает, но использование Ctrl-Alt для доступа к тем же клавишам клавиатуры не работает надежно (если вообще работает).

В версии 0.2.1831.0 комбинации AltGr теперь работают с финской клавиатурой.

@solispauwels - единственные исправления в версии 0.2.1831.0 упомянуты в примечаниях к выпуску.

Обратите внимание, что многие ОС 1803 или более поздних версий могут столкнуться с ошибкой в ​​Магазине Windows версии 11905.1001.4.0.
Магазин будет «складывать» приложения для загрузки (см. Изображение), но не будет загружать приложения, даже если включена автоматическая загрузка и сеть не является лимитным соединением.

Затронутые пользователи должны нажать «Проверить наличие обновлений» в Microsoft Store, чтобы в конечном итоге получить фиксированное приложение Store и инициировать все ожидающие загрузки приложений.

Я подтверждаю, что эта проблема будет исправлена ​​в новой версии Терминала. Большое спасибо.

Я также могу подтвердить, что сейчас это исправлено. Возможно, вы захотите открепить проблему.

Он работает, кроме клавиши евро, которая является AltGr + e, по крайней мере, на испанской клавиатуре. Остальные комбинации работают исправно

От @ifilgud

Он работает, кроме клавиши евро, которая является AltGr + e, по крайней мере, на испанской клавиатуре. Остальные комбинации работают исправно

Протестировано в Windows 10 1903 (18362.175) с использованием последней версии от 08.07.2019 с использованием клавиатуры AZERTY «бельгийская (точка)».

Результат испытаний:

• все комбинации, доступные на моей клавиатуре, включая символ валюты евро (€), работают в 2 из 3 консолей, настроенных по умолчанию в Терминале Windows: PowerShell Core и cmd (командная строка Windows)
• Только в "Windows PowerShell" символ евро (€) не работает
  
  
  
  • Однако это работа в PowerShell Классической консоли не запускается непосредственно из ОС Windows Start , а также
  
  

Imo, это новая проблема, связанная с Windows PowerShell, не относящаяся к терминалу Windows, на котором размещена эта консоль.

Подтверждаю наблюдение @DeChrist . С другой стороны, нажатие Ctrl-Alt + (Key) не работает должным образом (если кто-то хочет использовать эту комбинацию вместо AltGr).

Здесь на Windows 10 сборки 18362.175 под управлением Windows Terminal Preview версии 0.2.1831.0, с французской клавиатуры, AltGr+E это выход € во всех следующих оболочек:

• cmd
• Windows PowerShell 5.1
• PowerShell Core 6.2.1
• PowerShell Core 7.0.0-превью.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

• Windows 10 1903 г.
• Терминал Windows 0.2.1831.0
• PowerShell v7 (включая PSReadline 2.0.0-beta4)
• Немецкая раскладка клавиатуры QWERTZ

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

Это особенно расстраивает, поскольку есть еще одна ошибка, связанная с mstsc которую Microsoft игнорирует как минимум десять лет, когда AltGr + Q перестает работать, если открыт сеанс RDP. В этих ситуациях 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 -...

У вас есть только ОДНА возможность сделать это правильно. Первая возможность почти за 40 лет. Пожалуйста, не упускайте эту возможность - Microsoft, я смотрю на вас :)

@thorsig ах, если бы вы были рядом, когда стек ввода Win32

• как символы, без модификаторов (поэтому мы не можем обнаружить ALT, чтобы отправить его через терминальные каналы) или направление нажатия клавиш
• как скан-коды, которые имеют модификаторы и направления, но на самом деле являются просто представлениями _физических ключевых местоположений_

Когда вы начинаете смотреть ниже уровня операционной системы, сканирующие коды _являются_ режимом «как можно более необработанного ввода». Однако они требуют некоторой подготовки, прежде чем их можно будет передать приложениям, требующим ввода текста. (Правка, чтобы добавить :) Терминальные приложения действительно предпочитают вводить текст в виде текста. Мы не можем отправлять скан-коды через SSH-соединение! Даже если бы мы могли, получатель сам должен был бы понимать раскладку клавиатуры для выполнения перевода. Вероятно, у безголовых машин нет раскладки клавиатуры. (/редактировать)

Если бы это было так просто, как «получить буквальный символ, который они нажали, и отправить его», вы должны верить, что мы бы сделали именно это. Мы не придумываем сумасшедшие решения, потому что мы сумасшедшие люди! :улыбка:

Ну, я был рядом, хотя в то время я, возможно, не имел большого представления о том, как обрабатывать входной поток.

Однако Linux по умолчанию работает с необработанными кодами клавиш, так что это не проблема. Однако ваш пример ssh-соединения ошибочен, поскольку ssh никогда не выполняется непосредственно терминальным приложением - внутри (или целая абстракция ОС, такая как WSL) есть оболочка, которая отвечает за то, что достигает оболочки.

Если то, что вы утверждаете, было бы правильным, каждое приложение, когда-либо написанное для Windows (работающее поверх проводника), должно было бы реализовать свою собственную внутреннюю обработку клавиатуры. Они этого не делают. Потому что это касается восходящего и нисходящего потока.

Я просмотрел код и получил свою долю «SMH». Могу я сделать это лучше? Со временем, наверное. Могу ли я позволить себе жаловаться на это? Учитывая, что у меня нет времени на это самому - наверное, нет.

Я все еще считаю, что стоит упомянуть, что он как есть перерабатывается, и это вызовет проблемы в какой-то момент (вероятно, раньше, чем позже).

Ну, я был рядом, хотя в то время я, возможно, не имел большого представления о том, как обрабатывать входной поток.

Однако Linux по умолчанию работает с необработанными кодами клавиш, так что это не проблема. Однако ваш пример ssh-соединения ошибочен, поскольку ssh никогда не выполняется непосредственно терминальным приложением - внутри (или целая абстракция ОС, такая как WSL) есть оболочка, которая отвечает за то, что достигает оболочки.

WSL не выполняет какого-либо конкретного перевода. conhost.exe или терминал Windows (или терминал Gnome, если вы запускаете графическое приложение, скажем, через XMing) выполняет правильный перевод для отправки в pty. И даже оболочка ... большую часть работы выполняет не сама оболочка. Это драйвер терминала и приложение на главном конце (это, опять же, conhost.exe, Windows Terminal, возможно Cygwin Terminal, если хотите, и терминальные приложения Linux).

Если то, что вы утверждаете, было бы правильным, каждое приложение, когда-либо написанное для Windows (работающее поверх проводника), должно было бы реализовать свою собственную внутреннюю обработку клавиатуры. Они этого не делают. Потому что это касается восходящего и нисходящего потока.

Большинство приложений на самом деле не заботятся о необработанном вводе с клавиатуры. Это обрабатывается некоторыми библиотеками Win32 способами, которые по своей сути являются потерянными. Они не используют прямой ввод с клавиатуры. Большинство приложений заботятся только о персонажах, кроме игр, которые могут заботиться именно о вводе физического макета. В любом случае работает нормально.

Я просмотрел код и получил свою долю «SMH». Могу я сделать это лучше? Со временем, наверное. Могу ли я позволить себе жаловаться на это? Учитывая, что у меня нет времени на это самому - наверное, нет.

Я все еще считаю, что стоит упомянуть, что он как есть перерабатывается, и это вызовет проблемы в какой-то момент (вероятно, раньше, чем позже).

Я предлагаю вам заглянуть в Gnome-Terminal, аналог Linux, и проверить, проще он или сложнее. Я подозреваю, что это сложнее, поскольку 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]

У меня датская клавиатура и сборка Windows v0.3.2142.0 10.0.18362.239. Это английская операционная система без языковых пакетов. Здесь работают специальные символы Alt Gr, последовательность Ctrl + Alt - нет.

У меня датская клавиатура и сборка Windows v0.3.2142.0 10.0.18362.239 Это английская операционная система без каких-либо языковых пакетов. Здесь работают специальные символы Alt Gr, последовательность Ctrl + Alt - нет.

Мои ОС: Win10 Home 1903, сборка 10.0.18362.267
Датская операционная система с установленным дополнительным языковым пакетом для США, хотя датский языковой пакет установлен по умолчанию.
Хм - Build 10.0.18362.267 vs 10.0.18362.239 - есть ли подсказка? !!!

Мои ОС: Win10 Home 1903, сборка 10.0.18362.267
Датская операционная система с установленным дополнительным языковым пакетом для США, хотя датский языковой пакет установлен по умолчанию.
Хм - Build 10.0.18362.267 vs 10.0.18362.239 - есть ли подсказка? !!!

Чтобы получить все подробности:
Я на
Win 10 Enterprise en-US 1903, сборка 18362.239
Датская клавиатура, без языкового пакета

Просто попытался войти в учетную запись с языковым пакетом для США по умолчанию, - установил там терминал и переключился на датскую клавиатуру, чтобы посмотреть, влияет ли выбранный языковой пакет, но там не повезло.

Не знаю, может ли это быть подсказкой для кого-то в курсе, но до обновления до 1903 года с 1809 экранная клавиатура ( c:\windows\system32\osk.exe ) показывала такое же поведение во всех приложениях conhost, cmd.exe, ubuntu / wsl и powershell.exe (игнорируя AltGr), но в 1903 году это кажется исправленным.

Я могу подтвердить, что некоторые последовательности 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 Terminal Preview 0.3.2142.0

@ sba923 У меня тоже французская клавиатура и такая же версия для Windows. Комбинации AltGr, которые не работают, следующие: & ~ # {[| `\ ^ € ù \
Мой терминал тоже скачивается из магазина. Попробую построить на местном уровне, чтобы посмотреть.

Чтобы уточнить мою ситуацию, - некоторые комбинации AltGr + Key действительно работают, а некоторые - нет.

Не работает:

| Ключ | AltGr + Key, ожидается: |
| ----- | ----------------------- |
| '2' | '@' |
| '3' | '£' |
| '4' | '$' |
| '7' | '{' |
| '8' | '[' |
| '9' | ']' |

Работает:

| Ключ | AltGr + Key, ожидается: |
| ----- | ----------------------- |
| '0' | '}' |
| '´' | '|' |
| '<' | '\' |
| '¨' | '~' |
| 'e' | '€' |

Примечание: «´», «¨» - это мертвые ключи.

Система: Windows 10, 64-разрядная, Домашняя, 1903, сборка 10.0.18362.267
Windows Terminal: Preview v0.3.2142.0 - версия магазина
Раскладка клавиатуры: датская.

@MasMedIm , @ sba923 , @lhecker - Ваши версии Windows Home похожи на мою?
Изменить: забудь мой вопрос. Я собирался начать там погоню за дикими гусями ;-), но

@ DHowett-MSFT @ henrik-jensen et. др .: Я нашел причину регресса. ¯ \ _ (ツ) _ / ¯
... и это делает всех нас здесь кучкой идиотов, которых мы раньше не заметили. 😂

Новый profiles.json содержит ярлыки типа Ctrl+Alt+[0-9] для быстрого перехода к вкладкам 1-10.
Если вы удалите эти ярлыки из файла настроек ( Ctrl , ), регресс будет исправлен.
Некоторые комбинации, такие как AltGr E для € сожалению, еще никогда не работали, и кому-то нужно время, чтобы исправить это.

Из-за того, как работают старые Windows API, будет сложно надежно отличить сочетания клавиш Alt от фактических нажатий клавиш AltGr , но я собираюсь проверить, можно ли как-то улучшить ситуацию.

@lhecker 🥇 👍
Подтверждено. Jubii

Некоторые комбинации, такие как AltGr E для € сожалению, никогда не работали, и кому-то нужно время, чтобы исправить это.

AltGr E -> '€' действительно работает с моей датской раскладкой клавиатуры. Я попробую добавить немецкую раскладку к себе, чтобы посмотреть, воспроизводится ли она на моей установке.

Как насчет того, чтобы просто укусить пулю? Сохранить старый CMD.EXE для устаревших (DOS) приложений и разработать новый Терминал только для будущего? Не то чтобы обратная совместимость не была хорошей, но иногда вам просто _ нужно_ разорвать связи ...

@lhecker 🥇 👍
Подтверждено. Jubii

Некоторые комбинации, такие как AltGr E для € сожалению, никогда не работали, и кому-то нужно время, чтобы исправить это.

AltGr E -> '€' действительно работает с моей датской раскладкой клавиатуры. Я попробую добавить немецкую раскладку к себе, чтобы посмотреть, воспроизводится ли она на моей установке.

Установленные немецкие ~ Kezboard ~ ups, Keyboard :-) * и AltGr E -> '€' работают в этой настройке.

Изменить: * 'z' / 'y' меняются местами на немецкой / датской клавиатуре.

Новый profiles.json содержит ярлыки типа Ctrl+Alt+[0-9] для быстрого перехода к вкладкам 1-10.

По какой-то причине в моем файле настроек эти ярлыки - alt + [0-9], поэтому у меня не было проблемы

У меня возникают вопросы:

• @lhecker Может быть, нам стоит сделать новую проблему для регрессии для обнаруживаемости / истории, и вы можете добавить к ней свой патч? Изменить: Отлично - @lhecker сделал запрос на
• Интересно, где по умолчанию создается ~ settings.json ~ profiles.json . Это не ресурс, поэтому я предполагаю, что это где-то жестко запрограммировано? Изменить: нашел CascadiaSettings.cpp L369
• Какие альтернативные ярлыки следует выбрать вместо этого. Может быть, те, которые есть у profiles.json (были ли они по умолчанию в версии до 0.3.2142.0? Edit: Кажется, так - # 2014)

@lhecker @ henrik-jensen, в этом есть смысл. Я установил из магазина сразу после того, как он был там выпущен, и я внес некоторые изменения в profiles.json Поэтому, если обновление не перезаписало файл, потому что он был индивидуальным, а не по умолчанию, я не получил ярлыки Ctrl + Alt

@ DHowett-MSFT @ henrik-jensen et. др .: Я нашел причину регресса. ¯_ (ツ) _ / ¯
... и это делает всех нас здесь кучкой идиотов, которых мы раньше не заметили. 😂

Новый profiles.json содержит ярлыки типа Ctrl+Alt+[0-9] для быстрого перехода к вкладкам 1-10.
Если вы удалите эти ярлыки из файла настроек (Ctrl,), регресс будет исправлен.
Некоторые комбинации, такие как AltGrE для € сожалению, никогда не работали, и кому-то нужно время, чтобы исправить это.

Из-за того, как работают старые API Windows, будет сложно надежно отличить сочетания клавиш CtrlAlt от фактических нажатий клавиш AltGr, но я собираюсь проверить, можно ли как-то улучшить ситуацию.

Тай для ответа, действительно, это были настройки Ctrl + Alt + [0-9]

@saadanerdetbare , Ага, здесь поменял с твоих настроек на новые # 2014 @ zadjii-msft

Я подтверждаю, что новые сочетания клавиш нарушают работу AltGr ( ~#{[|`\^@]} ) на моей французской клавиатуре.

Причина, по которой некоторые из нас не заметили регрессии, связана с тем, что обновление 0.3 не отменяет существующий profiles.json , что задокументировано в Windows Terminal Preview v0.3 Release :

Примечание. Если вы ранее устанавливали Терминал до этого выпуска, эти привязки клавиш будут отображаться по умолчанию только после того, как вы удалите файл profiles.json и дадите ему возможность регенерировать. Вы можете сохранить исходный файл profiles.json в другом месте и скопировать свои настройки или просто добавить эти привязки клавиш вручную. Мы понимаем, что это не идеальный опыт, и работаем над его улучшением.

Можно использовать ctrl + alt + shift + _digit_, хотя это не так просто ввести ...

@ henrik-jensen Я открыл # 2235.

@thorsig Вам уже рассказали, как
Особенно с учетом того, что, например, bash в Linux (как и большинство оболочек, которые вы, возможно, захотите использовать в Windows в будущем) _не_ получает необработанные коды клавиш, а скорее обычный текст, наполненный управляющими последовательностями. Последовательности выхода, которые ваш терминал должен генерировать из событий клавиатуры. Ваша оболочка Linux _не_ обрабатывает необработанные коды клавиш. Ваш терминал делает.
Прежде чем продолжить, вы должны сначала понять, как работают xterm и vt100 (и более поздние версии).
И, кстати, коды клавиш в Linux также представляют собой виртуальную (! = Необработанную) абстракцию над скан-кодами с клавиатуры - см. keymaps.5 . Единственное отличие состоит в том, что в Windows давным-давно было решено, что Ctrl + Alt - это то же самое, что и AltGr, потому что на некоторых клавиатурах не хватало клавиш AltGr, но кто-то все еще хотел иметь возможность как-то нажимать AltGr. Людей, которые так решили, сейчас может быть 60+. Изменить это нетривиально и имеет лишь незначительное преимущество (поскольку вы в любом случае уже можете обнаружить нажатия клавиш AltGr на практике).

Я подтверждаю, что новые сочетания клавиш нарушают работу AltGr ( ~#{[|`\^@]} ) на моей французской клавиатуре.

Причина, по которой некоторые из нас не заметили регрессии, связана с тем, что обновление 0.3 не отменяет существующий profiles.json , что задокументировано в Windows Terminal Preview v0.3 Release :

Примечание. Если вы ранее устанавливали Терминал до этого выпуска, эти привязки клавиш будут отображаться по умолчанию только после того, как вы удалите файл profiles.json и дадите ему возможность регенерировать. Вы можете сохранить исходный файл profiles.json в другом месте и скопировать свои настройки или просто добавить эти привязки клавиш вручную. Мы понимаем, что это не идеальный опыт, и работаем над его улучшением.

Можно использовать ctrl + alt + shift + _digit_, хотя это не так просто ввести ...

Легче использовать alt + _digit_, и он похож на ярлыки в gnome-terminal.
Он работает на моей французской клавиатуре.

Если вы используете Alt + цифра , имейте в виду, что вы не сможете отправить эти ключи в консольное приложение.

: 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 build 10.0.18362.267.
Удалил мой profiles.json чтобы получить настройки по умолчанию, и теперь AltGr также работает для новой установки (я полагаю).
Отличная работа, @lhecker и все остальные.

Привет, я думаю, что у меня эта проблема на версии 0.7.

Я не могу ввести косую черту на своей клавиатуре ни с помощью цифровой клавиатуры, ни с помощью AltGr + Q (бразильская клавиатура ABTN2 ноутбука Samsung, на которой нет вопросительного знака / косой черты).

Изменить: я не могу ввести любую клавишу 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, но это имеет другое поведение в зависимости от типа терминала, но ни в одном из них я не могу получить символ ~ напечатано, при этом выполняется непосредственно в базовой оболочке (git / cmd / powershell / wsl не встроено в терминал Windows) работает должным образом

Это происходит со мной с последней версией терминала Windows, на момент написания:

Windows Terminal (Preview)
Version: 0.8.10091.0)

@ilmax Я нарушил ввод Alt + Numpad в # 3117. Теперь, когда # 3117 был объединен и связанная с этим проблема исправлена, мы можем работать над повторным введением ввода цифровой клавиатуры в базу кода.
Я бы сделал это необязательным, настраиваемым поведением, потому что я совершенно уверен, что большинство потенциальных пользователей приложения Terminal больше не получат от этого выгоду. Таким образом, приложение должно по умолчанию отправлять в оболочку все возможные вводы с клавиатуры, чтобы вы могли настроить более продвинутые привязки клавиш vim и т. Д.
Реализация этого должна быть немного проще, как только # 4192 будет объединен. Вам нужно будет добавить дополнительную логику прямо здесь и проверить, удерживается ли клавиша Alt (и только клавиша Alt) в states , в то время как vkey происходит от цифровой клавиатуры, а не от обычных цифровых клавиш . Смело отправляйте PR в любое время! 🙂

@lhecker спасибо за быстрый ответ, я просто хотел узнать, в
Не уверен, что придумаю пиар по этому поводу, я никогда раньше не смотрел на код 😄 поэтому я действительно не знаю, с чего начать, несмотря на ваше предложение.

Я просто хотел знать, как исправить мой рабочий процесс для git rebase -i, потому что теперь мне нужно открыть что-то вроде notepad ++, ввести символ ~, скопировать его и вставить в терминал.

Я так понимаю: вы в теме про AltGr с вопросом о _alt + numpad последовательностях_? Возможно, поэтому все темы, которые вы обнаруживаете, закрыты: проблема с AltGr исправлена.

Я действительно считаю, что у нас есть отдельная проблема с отслеживанием проблем с вводом alt + numpad.

Да, вы правы, извините за недоразумение. Я думаю, № 657 может быть правильным