Xterm.js: Скандинавская раскладка клавиатуры не поддерживает ввод тильды (~)

Проблема с кодом VS: https://github.com/microsoft/vscode/issues/68262

@Tyriar, как xterm связано с vscode ?

vscode использует xterm, об этом сообщалось там.

У Terminus такая же проблема: https://github.com/Eugeny/terminus/issues/768
Это не ограничивается скандинавскими клавиатурами. По крайней мере, французский и испанский языки тоже затронуты (я полагаю, любой макет с клавишей AltGr и двухступенчатой ​​функцией акцентов).

Еще можно поймать ~ с помощью InputEvent :

Я не уверен, сработало ли это когда-либо, если InputEvent устраняет проблему, похоже, что это может быть та же основная причина, что и https://github.com/xtermjs/xterm.js/issues/469, и нам нужны чтобы переместить обработку ввода в input вместо ключевых событий.

@Tyriar Использование только InputEvent точно недостаточно. Его evt.data просто содержит текущую строку значения для input/textarea и ничего не говорит о нажатых клавишах и т. Д. Я просто подумал, что это может помочь исправить эту проблему в сочетании с обычным KeyboardEvent .

У меня такая же проблема с Fluent Terminal .
Я не могу ввести ~ , вместо этого отображается Þ . Моя клавиатура - PT-BR (с клавишей AltGr), но если я изменю раскладку на US, я могу ввести ~ с помощью клавиши ' .

Пока эта проблема не будет исправлена, я предлагаю использовать обходной путь отсюда

Я не уверен, что это точно такая же проблема, но я считаю, что ввод любых диакритических знаков (например, ö ầ и т. Д.), А не только тильды, в xterm вообще не работает (печатается как oa, без применены любые диакритические знаки). Протестировано с французской клавиатурой и Linux, последней версией xTerm.js на Hyper и / или eDEX-UI.

@GitSquared Я думаю, это может быть связано с вашей переменной $LANG ?

@Tyriar My $LANG установлен в en_US.UTF-8 но ввод диакритических знаков работает в других эмуляторах терминала (Konsole), и переключение, например, на fr_FR.UTF-8 не решает проблему. .

Кроме того, я не уверен, как $LANG влияет на ввод текста? Это какое-то специфическое для xterm.js поведение?

@Tyriar Это проблема только для Mac или клавиатур Mac (MBP)? У меня нет проблем с клавиатурами ПК с немецкой раскладкой клавиатуры - все смены третьего уровня работают так, как задумано во всех браузерах (проверено демо в chrome + FF).

Некоторые идеи, что идет не так (на самом деле это выглядит как две отдельные проблемы на нижнем уровне):

• исходный плакат, о котором сообщалось, что нажимается Alt + ^ : Alt по умолчанию имеет особое значение, мы сопоставляем его с клавишей Meta на клавиатуре ПК (поскольку в нем отсутствует выделенный Meta ключ). Это предположение может быть неверным для некоторых типов клавиатуры (Mac?). Для клавиатур Mac у нас есть настройка macOptionIsMeta , возможно, нам придется проверить, нужна ли для этого немного другая обработка клавиш Alt+XY в Keyboard.ts если она установлена.
• Проблема с fluentTerminal и AltGr: похоже, что движок браузера сообщает неправильный ключ / код клавиши (неправильное применение раскладки клавиатуры?). Когда AltGr обычно удерживается нажатой, сообщаемая запись должна сместиться на третий символ для второй клавиши. Если браузер ошибается, я боюсь, что мы мало что можем сделать. Но это все спекуляции, и для выявления всех крайних случаев требуется надлежащее тестирование ошибок. Если InputEvent прежнему сообщает правильное значение ключа, мы можем обойтись комбинированной обработкой KeyboardEvent + InputEvent . Если это не сработает, в крайнем случае может быть предоставлена ​​собственная (настраиваемая) раскладка клавиатуры.

Работа с клавишами всегда была головной болью в браузерах, может, мы сможем чему-нибудь научиться у парней из Монако?

Вещи, упомянутые в этой проблеме, трудно исправить до тех пор, пока мы не можем воспроизвести ее и не знаем точных обстоятельств, при которых эта ошибка обнаруживается (версия ОС + браузер). Есть ли добровольцы (частично) для решения этой проблемы?

Чтобы проверить, правильно ли сообщает браузер, вы можете использовать https://w3c.github.io/uievents/tools/key-event-viewer.html.

Это проблема только для Mac или клавиатур Mac (MBP)?

@jerch , возможно, вы правы, OP, и все 2 связанных проблемы vscode находятся на macos.

К вашему сведению, ряд закрытых / повторяющихся проблем в репозитории VSCode привел меня к этой проблеме, и я использую Windows. При использовании французской раскладки AZERTY тильда находится в строке «number», на клавише «2», которая имеет в качестве основного символа «é», сдвига char «2» и третьего символа «~», который обычно имеет мертвую клавишу. поведение. Таким образом, чтобы ввести символ ~, нормальной последовательностью будет AltGr + é, Space. Однако при этом результат будет é~ .

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

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

Так что, если вы не возражаете - не могли бы вы также проверить, ошибочны ли и другие третьи смены (я так полагаю)? И правильно ли сообщает https://w3c.github.io/uievents/tools/key-event-viewer.html - если да, то это проблема с нашей стороны.
Также сообщите нам версию вашей ОС и установленный язык / раскладку клавиатуры. (Еще не уверен, я думаю, что браузер пытается применить настройку раскладки клавиатуры ОС для кодов событий, поэтому это также может быть источником проблем в зависимости от конфигурации).

Изменить: вот список распространенных раскладок латинской клавиатуры https://en.wikipedia.org/wiki/List_of_Latin-script_keyboard_layouts (и ссылки на другие раскладки в нижнем колонтитуле). И спецификация ISO для клавиатур https://en.wikipedia.org/wiki/ISO/IEC_9995.

Хорошо, поэтому я попытался воспроизвести на экземпляре Docker xterm.js, но не смог воспроизвести (и Firefox, и Chrome). Я использую Windows 10, и моя ошибка возникает в терминале VSCode (1.38.1). 🤷‍♂

@laarmen О, это странно, я почти уверен, что vscode выполняет точно такой же код для ввода с клавиатуры без изменений.

@Tyriar FYI. Может быть, электронная ошибка неправильного применения раскладки клавиатуры ОС?

@rebornix вы видели какие-нибудь отчеты по этому поводу для Монако?

Для меня на macOS, финская клавиатура, Safari и Chrome, тильда + пробел приводит к ~, а тильда + n дает - как и должно. Но в Firefox тильда + пробел приводит к ~~, а тильда + n дает ~ ññ.

Интересно, что это различие в поведении можно увидеть (но по некоторым причинам немного иначе) на примере терминала домашней страницы https://xtermjs.org/ . Если вы введете тильду + пробел в Safari, вы ничего не получите. То же самое для тильды + n. Но с Firefox, когда тильда + пробел ничего не дает, тильда + n ничего не дает -. Не уверен, почему там по-другому работает.

Журнал отладки показывает следующее при вводе тильды + пробел в Firefox:

xterm.js: sending data "~" Array [ 126 ]
xterm.js: sending data "~" Array [ 126 ]
xterm.js: parsing data ~~

Для тильды + n это показывает:

xterm.js: sending data "~" Array [ 126 ]
xterm.js: sending data "ñ" Array [ 241 ]
xterm.js: sending data "ñ" Array [ 241 ]
xterm.js: parsing data ~
xterm.js: parsing data ññ

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

Я должен добавить, что ничего не отправляется, пока вы не нажмете пробел или n. То есть начальная тильда, с которой начинается композиция символа, не приводит к срабатыванию каких-либо обратных вызовов, что является правильным.

Последовательность записи событий клавиатуры путем присоединения пользовательского обработчика клавиатуры с помощью API терминала для тильды + n в Windows Firefox (71) с финской клавиатурой следующая:

keydown Control { target: textarea.xterm-helper-textarea, key: "Control", charCode: 0, keyCode: 17 }
keydown { target: textarea.xterm-helper-textarea, key: "AltGraph", charCode: 0, keyCode: 18 }
keydown { target: textarea.xterm-helper-textarea, key: "Dead", charCode: 0, keyCode: 160 }
keyup { target: textarea.xterm-helper-textarea, key: "Dead", charCode: 0, keyCode: 160 }
keyup { target: textarea.xterm-helper-textarea, key: "Control", charCode: 0, keyCode: 17 }
keyup { target: textarea.xterm-helper-textarea, key: "AltGraph", charCode: 0, keyCode: 18 }
keydown { target: textarea.xterm-helper-textarea, key: "ñ", charCode: 0, keyCode: 78 }
keyup { target: textarea.xterm-helper-textarea, key: "n", charCode: 0, keyCode: 78 }

В macOS с Firefox (71) с финской клавиатурой последовательность такова:

keydown Alt { target: textarea.xterm-helper-textarea, key: "Alt", charCode: 0, keyCode: 18 }
keydown Alt { target: textarea.xterm-helper-textarea, key: "Dead", charCode: 0, keyCode: 160 }
keyup Alt { target: textarea.xterm-helper-textarea, key: "~", charCode: 0, keyCode: 160 }
keyup { target: textarea.xterm-helper-textarea, key: "Alt", charCode: 0, keyCode: 18 }
keydown { target: textarea.xterm-helper-textarea, key: "ñ", charCode: 0, keyCode: 78 }
keyup { target: textarea.xterm-helper-textarea, key: "n", charCode: 0, keyCode: 78 }

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

Зарегистрированный выпуск № 2661

Здравствуйте,

У меня такая же проблема с интегрированным терминалом VSCode с французской раскладкой.
Я использую Windows 10 2004.
Когда я хочу ввести символ ~ , он выводит мне é~ ( Alt right + é затем space ).
Alt right + é (дважды), мне выводится éé~ .
Я могу воспроизвести проблему на xtermjs.org.

Я пытался собрать журналы / информацию, чтобы помочь вам. Если я правильно понимаю, вы не можете воспроизвести проблему на своей стороне, поэтому сообщите мне, если вам еще что-то нужно.

Отладка VSCode, прикрепленная onkeydown и oninput к console.log:

(é появляется в событии клавиатуры AltGraph).

Средство просмотра событий клавиатуры:

@tcardonne Я считаю, что это никогда не работало и происходит, потому что мы слушаем, используя события keydown / key / keyup, а не событие input , это та же причина, по которой поддержка эмодзи не очень хороша https: // github .com / xtermjs / xterm.js / вопросы / 469. Это изменение может быть относительно легко перенести, но поскольку это довольно фундаментальное изменение того, как работает ввод, потребуется много проверок и тестов.

@ Тириар, я понимаю.

Это странно, у меня дома проблема на рабочем столе, но я не могу воспроизвести ее на своем рабочем ноутбуке (с подключенной к нему такой же клавиатурой).
Я тестировал на сайте xtermjs.org и на vscode.
Единственная разница заключается в версии для Windows (2004 г. на персональном компьютере, 1903 г. на рабочем ноутбуке).

Вот таблица просмотра событий клавиатуры:

(обратите внимание на клавишу Dead )

Это может быть связано с разницей в настройках ОС, но я не могу найти никакой разницы. У вас есть идеи о настройках, которые могут повлиять на это поведение?

Хорошо, я чувствую себя глупо, я не заметил NumLock на моем первом комментарии.
У меня маленькая клавиатура без цифровой клавиатуры и функциональных клавиш, поэтому я этого не заметил.

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

Тем не менее, я рад, что нашел причину своей проблемы. Надеюсь, это поможет!

Я вижу, что https://github.com/microsoft/vscode/issues/98533 был помечен как дублированный для этого, но https://xtermjs.org/ может вводить любые символы áéíóú без каких-либо проблем, в то время как встроенный терминал vscode не может. ..

Я вижу, что microsoft / vscode # 98533 был помечен как дублированный для этого, но https://xtermjs.org/ может вводить любые символы áéíóú без каких-либо проблем, в то время как встроенный терминал vscode не может ...

Не согласен. Я также не могу вводить какие-либо символы áéíóú в демонстрации https://xtermjs.org/ с моей испанской клавиатурой.

Я вижу, что microsoft / vscode # 98533 был помечен как дублированный для этого, но https://xtermjs.org/ может вводить любые символы áéíóú без каких-либо проблем, в то время как встроенный терминал vscode не может ...

Не согласен. Я также не могу вводить какие-либо символы áéíóú в демонстрации https://xtermjs.org/ с моей испанской клавиатурой.

Может быть, это SO или браузер? Я использую firefox на kde Neon здесь

Я вижу, что microsoft / vscode # 98533 был помечен как дублированный для этого, но https://xtermjs.org/ может вводить любые символы áéíóú без каких-либо проблем, в то время как встроенный терминал vscode не может ...

Не согласен. Я также не могу вводить какие-либо символы áéíóú в демонстрации https://xtermjs.org/ с моей испанской клавиатурой.

Может быть, это SO или браузер? Я использую firefox на kde Neon здесь

Вы правы: я могу воспроизвести проблему с помощью Google Chrome, но символы áéíóú работают прямо в Firefox. :открытый рот:

@ricpelo Это похоже на проблему с "мертвыми" клавишами, которые ведут себя по-разному в FF, Chrome и Safari. Не могли бы вы попытаться записать события с помощью https://w3c.github.io/uievents/tools/key-event-viewer.html в FF и Chrome и опубликовать результаты здесь?

@jerch конечно. Здесь я иду:

Хром:

Fire Fox:

@ricpelo Спасибо большое. Проблема в следующем:

Хотя FF уже выдает накопленный мертвый ключ символ в финальном keydown в key , хром просто возвращает необработанный ключ. Я не уверен, кто здесь виноват, имхо клавиатура в keydown вообще не очень хорошо спроектирована. Он также показывает, что input правильно обрабатывает символы в обоих случаях. Это довольно веский аргумент для перехода на input (мы уже выяснили это выше).

Но input не может правильно поймать мета-клавиши, такие как Strg, Alt, AltGr (левый / правый вариант в OSX), особенно. Shift в комбинации, но они нам нужны в терминале для продвижения любых Strg + X и подобных. Я предполагаю, что нам нужен более сложный обработчик событий, который в основном полагается на input но выполняет другое оформление / перевод символа из состояний мета-ключей "закрытие" keydown / keyup events. Звучит противно, но должно быть выполнимо. Тем не менее, тестирование сложно выполнить (нет хорошего способа автоматизировать это без физического взаимодействия).

Есть новости по этому поводу? Есть ли предложенный пул-реквест или что-то подобное?