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: يبدو أن محرك المتصفح يبلغ عن المفتاح / keyCode الخاطئ (لا يتم تطبيق تخطيط لوحة المفاتيح بشكل صحيح؟). عندما يتم الضغط على AltGr بشكل طبيعي ، يجب أن يتحول الإدخال المبلغ عنه إلى الحرف الثالث للمفتاح الثاني ، إذا أخطأ المتصفح هنا ، أخشى أنه لا يوجد الكثير يمكننا القيام به في المقام الأول. لكن أجهزة الصراف الآلي هذه مجرد تكهنات وتحتاج إلى اختبار أخطاء مناسب للقبض على جميع حالات الحافة. إذا كان InputEvent لا يزال يُبلغ عن قيمة المفتاح الصحيحة ، فقد نحصل على معالجة مجمعة KeyboardEvent + InputEvent . إذا لم ينجح ذلك - فقد يكون الملاذ الأخير هو تقديم خرائط تخطيط لوحة المفاتيح الخاصة بنا (القابلة للتخصيص).

لطالما كان التعامل مع المفاتيح بمثابة ألم في ** في المتصفحات ، فربما يمكننا تعلم شيء ما من رجال موناكو هنا؟

يصعب إصلاح الأشياء المذكورة في هذه المشكلة طالما أننا لا نستطيع إعادة معالجتها ولا نعرف الظروف الدقيقة التي يظهر بها هذا الخطأ (إصدار نظام التشغيل + المتصفح). أي متطوعين (جزئيا) لمعالجة هذا؟

لاختبار ما إذا كان المتصفح يبلغ عن الشيء الصحيح ، يمكنك استخدام https://w3c.github.io/uievents/tools/key-event-viewer.html.

هل هذه مشكلة فقط في نظام Mac أو مع لوحات مفاتيح Mac (MBP)؟

jerch ، قد تكون على حق في OP وتكون مشكلتا vscode المرتبطتان كلها على macos.

لمعلوماتك ، تقودني سلسلة من المشكلات المغلقة / المكررة في مستودع VSCode إلى هذه المشكلة ، وأنا على Windows. باستخدام تخطيط AZERTY الفرنسي ، يكون التلدة في صف "الرقم" ، على المفتاح "2" ، والذي يحتوي على الحرف الرئيسي "é" ، و shift char "2" ، و الحرف الثالث "~" ، والذي عادةً ما يحتوي على مفتاح معطل سلوك. وبالتالي ، لكتابة حرف ~ ، سيكون التسلسل الطبيعي هو AltGr + é ، Space. ومع ذلك ، عند القيام بذلك تكون النتيجة é~ .

لست متأكدًا تمامًا من أنه نفس الخطأ بالضبط ، لكنني أفترض أنه ينبع من نفس الأسباب الجذرية.

laarmen يبدو أنه

لذا إذا كنت لا تمانع - هل يمكنك أيضًا التحقق مما إذا كانت التحولات الثالثة الأخرى خاطئة أيضًا (أفترض ذلك)؟ وما إذا كان 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 يعمل بالضبط نفس الكود لإدخال المفتاح دون تغيير.

تضمين التغريدة ربما خطأ إلكتروني لا يطبق تخطيط لوحة مفاتيح نظام التشغيل بشكل صحيح؟

rebornix هل رأيت أي تقارير حول هذا الأمر لموناكو؟

بالنسبة لي على macOS ، لوحة المفاتيح الفنلندية ، مع Safari و Chrome ، ينتج عن التلدة + مسافة ~ و tilde + n ينتج ñ كما ينبغي. ولكن في Firefox ، ينتج عن علامة التلدة + مسافة ~~ وتؤدي علامة التلدة + n إلى ~.

من المثير للاهتمام أن هذا الاختلاف في السلوك يمكن رؤيته (ولكن بشكل مختلف قليلاً لسبب ما) على https://xtermjs.org/ محطة مثال الصفحة الرئيسية. إذا قمت بإدخال tilde + space هناك على Safari ، فلن تحصل على أي شيء على الإطلاق. نفس الشيء بالنسبة للتلدة + n. ولكن مع Firefox بينما لا تحصل على tilde + space ، لا تحصل علامة التلدة + 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 ññ

لاحظ أن هناك اختلافات في المتصفحات فيما يتعلق بما يتم الإبلاغ عنه من على سبيل المثال تكوين مقابل إدخال مقابل keydown مقابل أحداث ضغط المفتاح.

يجب أن أضيف أنه لا يتم إرسال أي شيء حتى تضغط على مسافة أو ن. أي أن التلدة الأولي الذي يبدأ تكوين الحرف لا ينتج عنه إطلاق أي نداءات ، حيث يكون whch صحيحًا.

تسلسل تسجيل أحداث لوحة المفاتيح عن طريق إرفاق معالج لوحة مفاتيح مخصص باستخدام Terminal API ، بالنسبة إلى tilde + 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 وإرفاق عند التشغيل وإدخال إلى console.log:

(تظهر علامة é في حدث لوحة مفاتيح AltGraph).

عارض أحداث لوحة المفاتيح:

tcardonne أعتقد أن هذا لم ينجح أبدًا ويحدث لأننا نستمع باستخدام أحداث keydown / key / keyup بدلاً من حدث input ، وهذا هو نفس السبب في أن دعم الرموز التعبيرية ليس رائعًا https: // github .com / xtermjs / xterm.js / قضايا / 469. قد يكون من السهل نسبيًا نقل هذا التغيير ، ولكن نظرًا لأنه تغيير أساسي جدًا لكيفية عمل المدخلات ، فسوف يحتاج إلى الكثير من التحقق من الصحة والاختبارات.

Tyriar أفهم.

إنه أمر غريب ، لدي مشكلة على سطح المكتب في المنزل ولكن لا يمكنني إعادة إنتاجها باستخدام الكمبيوتر المحمول الخاص بالعمل (مع لوحة المفاتيح نفسها المرفقة به).
لقد اختبرت على موقع xtermjs.org وعلى vscode.
يبدو أن الاختلاف الوحيد هو إصدار Windows (2004 على الكمبيوتر الشخصي ، 1903 على الكمبيوتر المحمول للعمل).

هنا جدول عارض أحداث لوحة المفاتيح:

(لاحظ المفتاح Dead )

قد يكون هذا متعلقًا باختلاف في إعدادات نظام التشغيل ، لكن لا يمكنني العثور على أي اختلاف. هل لديك أي فكرة عن الإعدادات التي قد تؤثر على هذا السلوك؟

حسنًا ، أشعر بالغباء ، لم ألاحظ NumLock في تعليقي الأول.
لدي لوحة مفاتيح صغيرة بدون لوحة أرقام ومفاتيح وظيفية ، لذلك لم ألاحظ ذلك.

ومع ذلك ، حتى مع num lock ، يجب أن يعمل ، لذا فإن المشكلة الأساسية (استخدام حدث الإدخال) لا تزال موجودة ، على ما أعتقد.

ومع ذلك ، يسعدني العثور على سبب مشكلتي. آمل أن يساعد!

أرى أن 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 ونشر النتائج هنا؟

تضمين التغريدة ها أنا ذا:

كروم:

ثعلب النار:

تضمين التغريدة تأتي المشكلة من هذا:

بينما يعطي FF بالفعل الحرف المتراكم للمفتاح الميت في keydown الأخير في key ، فإن الكروم يُرجع فقط المفتاح الخام. لست متأكدًا من المسؤول عن إلقاء اللوم هنا ، فأشياء لوحة المفاتيح في keydown ليست محددة جيدًا على الإطلاق. كما يوضح أيضًا أن input يحصل على الأحرف الصحيحة في كلتا الحالتين. هذه حجة قوية للانتقال إلى input (لقد توصلنا إلى ذلك أعلاه).

لكن input يواجه صعوبات في التقاط مفاتيح التعريف بشكل صحيح مثل Strg و Alt و AltGr (الخيار الأيسر / الأيمن في OSX) ، esp. التحول معًا ، لكننا نحتاج إلى تلك الموجودة في المحطة للترويج لأي Strg + X وما شابه. أعتقد أننا بحاجة إلى معالج حدث أكثر تعقيدًا ، والذي يعتمد أساسًا على input ولكنه يقوم بعمل زخرفة / ترجمة أخرى للحرف من الحالات الرئيسية الوصفية "تضمين" keydown / keyup أحداث

أي أخبار عن هذا الموضوع؟ هل هناك طلب سحب مقترح أو شيء مشابه؟