Xterm.js: ابتكر قصة جيدة لدعم ربط المفاتيح المخصص (غير Xterm)

تم إنشاؤها على ١٧ يناير ٢٠١٧  ·  25تعليقات  ·  مصدر: xtermjs/xterm.js

ندعم حاليًا أشياء مثل alt + arrow لتخطي الكلمات التي يتم إجراؤها عن طريق تجاوز تسلسل الهروب الذي نرسله إلى pty. يجب أن ننظر في جعل هذا قابلًا للتكوين باستخدام إعدادات افتراضية آمنة بحيث يمكن للمستهلك (المستهلكين) إيقاف تشغيله / تكوينه إذا رغبوا في ذلك.

out-of-scope typenhancement

التعليق الأكثر فائدة

من @ peabnuts123 في https://github.com/Microsoft/vscode/issues/11314#issuecomment -301634061

في OSX ، يعد "Use Option as Meta Key" إعدادًا في تطبيق Terminal الافتراضي. كل هذا يفعله هو تغيير وظيفة الخيار لإرسال مفتاح Meta بدلاً من ذلك (على عكس كتابة أحرف خاصة مثل ∂ ، ليس مفيدًا جدًا في Terminal IMO). ثم يتم استخدام مفتاح Meta لأي شيء بواسطة أي تطبيق تقوم بتشغيله داخله. قائمة الميزات التي "يجب" على مفتاح الخيار "القيام بها" ليست في الحقيقة الحل المناسب لذلك. على سبيل المثال ، عند استخدام tmux ، لدي Meta-Z مرتبط كبادئة للأوامر ؛ لتقسيم جزء ، اضغط أولاً على Option-Z (Meta-Z) ثم اضغط على \ . هذا لا يعمل في محطة VSCode المتكاملة ، ولن يعمل أي قدر من توثيق الميزات على إصلاح ذلك.

أعتقد أن التغيير المطلوب هنا هو خيار مماثل للمحطة المدمجة في OSX لدعم مفتاح Meta داخل الجهاز. أدرك أن هذا قد يكون مشكلة مع المكتبة الطرفية الأساسية نفسها ، مع ذلك.

ال 25 كومينتر

قد يكون هذا خيارًا يشبه keyMap ، حيث يمكننا تعيين ارتباطات المفاتيح أو رموز الهروب إلى الإجراءات الطرفية.

كيف يبدو هذا؟

شيء من هذا القبيل هو ما كنت أفكر فيه ، ولكنه يصبح صعبًا في حالة مثل ctrl+v حيث أعتقد أن تسلسل الهروب الذي ننشئه هو نفسه v

هذا هو السبب أيضًا في عدم قدرتنا على استخدام ملف ~/.inputrc للحصول على خيار + مسافة للخلف لحذف كلمة على Mac.

لقد كنت أفكر كثيرًا في هذا مؤخرًا ، ها هي فكرتي (مع الأخذ في الاعتبار العديد من القضايا المفتوحة على هايبر ذات الصلة بهذا الموضوع):

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

استخدم إيماءة لوحة المفاتيح للهروب من المحطة
الفكرة هي أنه إذا نقرت نقرًا مزدوجًا على مفتاح تعديل (ctrl ، alt ، shift ، meta؟) ، فلن يتم إرسال المفتاح إلى الجهاز ، ولكن سيتم إعادة توجيهه إلى المستخدم ، حتى يتمكن تطبيقه من استهلاكه. بدون النقر المزدوج ، سيتم استهلاك المفتاح (المفاتيح) بواسطة الجهاز.

مثال: لن يتم استهلاك ctrl...ctrl+x أو alt...alt+left بواسطة المحطة ولكن سيتم إعادة توجيهها كـ ctrl+x و alt+left للمستخدم.

هناك بعض حالات الحافة التي يجب أن نأخذها في الاعتبار:
لنفترض أنك تريد التبديل بين علامات تبويب أحد التطبيقات ، باستخدام ctrl+alt+left و ctrl+alt+right . الآن ، للانتقال إلى الجزء الأيمن ، يجب الضغط على ctrl...ctrl+alt+left . ولكن إذا كنت تريد القفز بين جزأين إلى اليسار على التوالي ، فأنت لا تريد الضغط على ctrl...ctrl+alt+left ctrl...ctrl+alt+left ، فأنت تريد الضغط على ctrl...ctrl+alt+left left . يجب أن يكون هذا سهل التنفيذ إلى حد ما ، ولكن يجب مراعاته.

بالإضافة إلى ذلك ، بالنسبة إلى ctrl+c الأكثر استخدامًا ، يجب أن نسمح له بالنسخ إذا تم تحديد النص ، وإلا يجب أن نكتب تسلسل التحكم إلى المحطة.

لصق يمكن القيام به مع ctrl...ctrl+v ، زر الماوس الأوسط أو الأيسر.

mofux لـ VS Code لقد أدخلت إعداد commandsToSkipShell الذي يسرد مجموعة من الأوامر التي لن تتم معالجة روابط المفاتيح الخاصة بها بواسطة xterm.js. لذلك يجب أن تكون قادرًا على اعتراض مثل هذه الحالات باستخدام Terminal.attachCustomKeydownHandler والتعامل معها كما تريد على مستوى أعلى (ctrl + c + text محدد -> نسخ ، ctrl + c + لم يتم تحديد نص -> إرسال إلى xterm .js).

يدور تفكيري الشخصي حول جعل xterm.js يتعامل مع روابط المفاتيح الشائعة التي ليست قياسية ولكنها مرغوبة بشكل عام ، ولكنها تسمح للمستهلكين بالانسحاب و / أو التعامل معها بأنفسهم.

أوه ، أرى أن وجود خريطة للإجراءات (على سبيل المثال "JUMP_WORD_LEFT") وربط مفاتيح افتراضي ولكن قابل للتخصيص له سيكون أمرًا منطقيًا بالتأكيد. قد يكون من المفيد الحصول على مخطط يبدو كالتالي:

{
  "COPY": { "mac": "cmd+c", "win": "ctrl+c", "default": "ctrl+c" },
  "JUMP_WORD_LEFT": { "default": "alt+left" }
}

default هو الإجراء الاحتياطي إذا لم يتم تحديد ربط النظام الأساسي الحالي.

يستخدم Hyper lib يسمى mousetrap للسماح بتفسير سلاسل المفاتيح مثل أعلاه.

نعم شيء من هذا القبيل ، أعتقد أن هذا هو نوع المعلومات التي نحتاجها لتشفير:

"mac": {
  "alt+delete": "\x17"
}

سيؤدي الضغط على alt + delete إلى إرسال \x17 ( ^W ) إلى pty.

وهو مشابه لتنسيق ملف .inputrc ، ولكنه يسمح بتجاوز ضغطات المفاتيح الفعلية في حالات مثل alt + delete حيث يؤدي كل من delete و alt + delete إلى إرجاع نفس تسلسلات الهروب .

راجع https://github.com/sourcelair/xterm.js/issues/486 و http://stackoverflow.com/a/29773694/1156119

لذا ، هل يجب أن نستقر في خيار يسمى keyMap ؟

هل سيعمل التنسيق التالي أيضًا؟

{
  "all": {
    "ctrl+space": "\x00"
  },
  "mac": {
    "alt+delete": "\x17"
  },
  "win": {
    "ctrl-v": null
  }
}

يبدو جيدًا ، هل يجب إنشاء keyMap الافتراضي أولاً قبل المضي قدمًا والتنفيذ للتأكد من أنه يغطي جميع الحالات؟ ها هي البداية:

{
  "all": {
    "alt+left": "\x1b[1;5D",
    "alt+right": "\x1b[1;5C",
    "alt+up": "\x1b[1;5A",
    "alt+down": "\x1b[1;5B",
    "ctrl+backspace": "\x17"
  },
  "mac": {
    "alt+left": "\x1bb", // Mac use different escape sequences to Linux for jumping word
    "alt+right": "\x1bf",
    "alt+delete": "\x17"
  }
}

عند كتابة هذا الأمر هناك حالة ctrl / shift + insert التي تتخطى الجهاز الطرفي ، فهل يجب على المستهلكين الآن التعامل مع ذلك إذا أرادوا ذلك عبر attachCustomKeydownHandler ؟

حسنًا ، لقد أنشأت Git هذا باعتباره ارتباطات للمفاتيح mac فقط ، بناءً على تكوين Terminal.app (الذي تركته افتراضيًا):

https://gist.github.com/parisk/f2d7eb8bd5584d9969c2449eee9d052c

السؤالان اللذان يدوران في ذهني الآن هما:

  • [] هل يجب أن نحتفظ بخريطة (خرائط) المفاتيح في ملف (ملفات) .js حتى نتمكن من إضافة تعليقات بجوار كل سطر؟
  • [] هل يجب أن نرسل سلاسل فقط إلى المحطة أم يجب أن نكون قادرين على "توجيهها" لتشغيل "أمر" دلالي (على سبيل المثال ، قم بتوجيهه لإدخال تغذية سطر)

يمكن أن يكون لدينا KeyMap.ts / Options.ts الذي يقوم بتصدير الملف الافتراضي بحيث يتم فصله بشكل جيد.

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

من LeviticusMB في https://github.com/Microsoft/vscode/issues/11314#issuecomment -274280543

الأساسيات: مفاتيح الأسهم ، مسافة للخلف ، d (حذف الكلمة الحالية) ، c (الأحرف الكبيرة) ، l (الأحرف الصغيرة) ، u (الأحرف الكبيرة) ولكن انظر https://en.wikipedia.org/wiki/GNU_Readline و http: // www. aboutlinux.info/2005/08/bash-shell-shortcuts.html.

Tyriar ، هل لدى Gnome3 أي روابط معينة تستحق المشاركة ، إلى جانب الروابط المذكورة في التعليق أعلاه؟

ليس هذا ما اخاف منه

من @ peabnuts123 في https://github.com/Microsoft/vscode/issues/11314#issuecomment -301634061

في OSX ، يعد "Use Option as Meta Key" إعدادًا في تطبيق Terminal الافتراضي. كل هذا يفعله هو تغيير وظيفة الخيار لإرسال مفتاح Meta بدلاً من ذلك (على عكس كتابة أحرف خاصة مثل ∂ ، ليس مفيدًا جدًا في Terminal IMO). ثم يتم استخدام مفتاح Meta لأي شيء بواسطة أي تطبيق تقوم بتشغيله داخله. قائمة الميزات التي "يجب" على مفتاح الخيار "القيام بها" ليست في الحقيقة الحل المناسب لذلك. على سبيل المثال ، عند استخدام tmux ، لدي Meta-Z مرتبط كبادئة للأوامر ؛ لتقسيم جزء ، اضغط أولاً على Option-Z (Meta-Z) ثم اضغط على \ . هذا لا يعمل في محطة VSCode المتكاملة ، ولن يعمل أي قدر من توثيق الميزات على إصلاح ذلك.

أعتقد أن التغيير المطلوب هنا هو خيار مماثل للمحطة المدمجة في OSX لدعم مفتاح Meta داخل الجهاز. أدرك أن هذا قد يكون مشكلة مع المكتبة الطرفية الأساسية نفسها ، مع ذلك.

كلما فكرت في هذا الأمر ، أعتقد أنه يجب التعامل معه على مستوى أعلى من xterm.js. تحتوي معظم أدوات التضمين على بعض أنظمة ربط المفاتيح الأكثر تميزًا مما يمكن أن يقدمه xterm.js (Hyper و VS Code على سبيل المثال) ، خاصةً إذا كنا نحاول تقليل الانتفاخ. على هذا النحو ، أقترح أن نغلق هذا الأمر ونوجه تعليمات إلى أدوات التضمين للتعامل مع هذا الأمر بأنفسهم ، وربما إعداد الأسئلة الشائعة على موقع الويب أيضًا؟

مرحبًا Tyriar - هل يمكنك من فضلك إخبارك بالتغييرات اللازمة لمستخدمي Mac OSX ليكونوا قادرين على alt meta . استخدام المحطة الطرفية الرائعة _Hyper_ ، والتي بالطبع تستخدم هذه المكتبة الأساسية الرائعة حقًا.

إليك الخطأ المقابل في Hyper: zeit / hyper # 2578. أي توصيات أو تلميحات حول التكوين المطلوب تغييره سيكون موضع تقدير كبير.

saamalik تحتاج ميزة "alt as meta" على macOS إلى دعم مضاف إلى xterm.js ، ثم ستحصل عليها Hyper عند الترقية. سيشمل ربط خيار جديد هنا:

https://github.com/xtermjs/xterm.js/blob/d33c340de548a3d579d11866fbffd83acd3ba277/src/Terminal.ts#L66

https://github.com/xtermjs/xterm.js/blob/d33c340de548a3d579d11866fbffd83acd3ba277/src/Interfaces.ts#L130

ثم استخدام الخيار حيث يتم إنشاء تسلسل الهروب من ضغطات المفاتيح:

https://github.com/xtermjs/xterm.js/blob/d33c340de548a3d579d11866fbffd83acd3ba277/src/Terminal.ts#L1404

Tyriar وأضاف. يُرجى إعلامي إذا كنت تريد مني إجراء أي تغييرات! لست متأكدًا أيضًا مما إذا كان من المفترض أن نقوم بفحص قفل الحزمة؟

saamalik من الأفضل ترك package-lock.json بالخارج ، لقد أضفته للتو في https://github.com/xtermjs/xterm.js/pull/1214 لذلك لست متأكدًا من سبب وجود الكثير من التغييرات بالنسبة لك 😕

Tyriar موافق على إزالة package-lock.json.

إغلاق هذا خارج النطاق. سيكون للتضمينات بشكل عام نظام ربط المفاتيح الخاص بها والذي سيكون أفضل من النظام الصغير الذي نرغب في القيام به لهذا الغرض ، وسيكون من الأفضل ترك هذا الأمر لهم بدلاً من تضمين نظام آخر يضيف سخامًا.

هل هناك أيضًا طريقة بسيطة لتحديث تعيينات المفاتيح؟ كما نفعل بشكل عام في Xdefaults ، سيكون ملف json واحدًا يمكنه استيعاب التكوينات وتجاوزها افتراضيًا أمرًا جيدًا.
أنا جديد على xterm ولكني أبحث عن هذا على وجه التحديد للكتابة فوق مفاتيح F1-F24. أي نصيحة هنا؟
تضمين التغريدة

krishnautpala قررنا السماح لك لمستخدم xterm.js بالتوصل إلى نظامك الخاص للتعامل مع روابط المفاتيح نظرًا لأن معظم المحطات / الأدوات سيكون لها نظامها الخاص على أي حال. إذا كنت بحاجة إلى تجاوز مفاتيح F ، فاستخدم واجهة برمجة التطبيقات هذه للتعامل مع المفاتيح يدويًا وإلغائها قبل أن تصل إلى xterm.js عن طريق إرجاع خطأ في المعالج:

https://github.com/xtermjs/xterm.js/blob/3504e2ebd577e609fd042850c51b52509efafe5a/typings/xterm.d.ts#L726 -L735

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات