Xterm.js: zsh / oh-my-zsh - بدون تمرير

شكرًا للإبلاغ عنwallverb. لا يمكنني الوصول إلى zsh في الوقت الحالي ، لذا لا يمكنني اختبار ذلك.

هل يمكنك إلقاء نظرة على وحدة التحكم الخاصة بك في أدوات المطور في متصفحك وتزويدنا بأي أخطاء / سجلات قد تظهر عند محاولة التمرير عندما تكون في zsh باستخدام oh-my-zsh؟

parisk - عندما يقوم zsh / oh-my-zsh بتنفيذ الأمر echoti smkx يتم إرسال البيانات التالية إلى Terminal.prototype.write = function(data) :

[?1l>
xterm.js:1467 


xterm.js:1467 ]2;echoti smkx
xterm.js:1467 ]1;echoti[?1h=[1m[7m%[m[1m[m    

والذي يبدو أن char = يسبب هذا:

 // ESC = Application Keypad (DECPAM).
              case '=':
                this.log('Serial port requested application keypad.');
                this.applicationKeypad = true;
                this.state = normal;
                break;

ثم this.applicationKeypad = true; يتسبب في إرجاع رمز التمرير:

      on(el, wheelEvent, function(ev) {
        if (self.mouseEvents) return;
        if (self.applicationKeypad) return;

parisk ، أي حركة لإصلاح هذا؟ حقا نقدر العمل!

richarddavenport للأسف لم يكن لدي الوقت للتعامل مع هذا ولا أتوقع أن أكون قادرًا على القيام بذلك بحلول نهاية الشهر.

سيكون من المفيد للغاية إذا تمكنا من الحصول على مساهمة خارجية في هذا الأمر ويمكنني بالتأكيد مساعدة أي شخص في اكتشاف العناصر الداخلية لـ xterm.js.

parisk أحب أن أساعد! هل هناك أي وثائق في أي مكان ، أو هل يمكنك مساعدتي في البدء في تصحيح الأخطاء؟ هل هناك محرر أو IDE يعمل بشكل أفضل؟ VS Code / Webstorm / Chrome Dev Tools؟ شكرا!

richarddavenport أي محرر يعمل بشكل جيد. جميع الكود في ./src/xterm.js والتعليمات لتشغيل العرض التوضيحي هنا .

richarddavenport أعتقد أن Tyriar على حق. يعمل أي محرر يدعم JavaScript ، لذا لا تتردد في اختيار المحرر الذي يناسبك بشكل أفضل.

على الرغم من ذلك ، قد يكون الرأي الشخصي هو اختيار محرر أو IDE يستخدم xterm.js نفسه ، من أجل تجربة التطبيق أيضًا (استخدم xterm.js عند تطوير xterm.js). الحلان اللذان أدركهما الآن هما:

• SourceLair الذي يعمل بشكل كامل في المتصفح ؛ ما عليك سوى زيارة https://lair.io/sourcelair/xterm واتباع التعليمات
• Visual Studio Code ، فقط قم بتنزيله ، استنساخ الريبو ، قم بتشغيل npm install وستكون جاهزًا

تصحيح الأخطاء باستخدام Chrome / Firefox DevTools هو أفضل طريقة للذهاب إلى IMO.

بالنظر إلى الوثائق ، لا يوجد موقع ويب عام في الوقت الحالي ولكن يجب أن تتوقع ذلك في غضون أسبوع. حتى ذلك الوقت ، ما عليك سوى تشغيل npm run build:docs في جهازك الطرفي ، وبعد ذلك ستتمكن من تصفح مرجع واجهة برمجة التطبيقات بتنسيق HTML ، داخل الدليل docs .

لا تتردد في طلب المزيد من المساعدة في حالة عدم كفاية ما ورد أعلاه.

richarddavenport لقد قمت بنشر نسخة معاينة من موقع الويب الخاص

يمكنك إلقاء نظرة على http://docs.xtermjs.org/. آمل أن يساعد 😊.

رائع! هذا رائع جدا! wallverb محق في الأمر echoti smkx في oh my zsh . يقوم هذا الأمر بوضع الجهاز في وضع التطبيق ، والذي (أظن هنا) مرتبط بالخاصية applicationKeypad . هل هذا يبدو صحيحا؟ ليس لدي أي فكرة عن وضع التطبيق ، لكنه يبدو مهمًا. السطر 1144 ، إذا تم التعليق عليه ، فكل شيء يعمل ، لكنني لست متأكدًا من العواقب أو سبب وجود هذا الخط. هل تعرف ما هذا؟

نعم ، أنا متردد قليلاً في لمسها لأنني لا أعرف ما الذي تفعله أيضًا.

هذا المستند المرجعي الذي نستخدمه ذكره هنا:

تنقل لوحة مفاتيح التطبيق تسلسلات الهروب التالية حسب-
جي في الوضع المحدد عبر تسلسل هروب DECKPNM و DECKPAM.
استخدم مفتاح NumLock لتجاوز وضع التطبيق.

يذكر الكود أيضًا:

              // ESC = Application Keypad (DECPAM).
              case '=':
                this.log('Serial port requested application keypad.');
                this.applicationKeypad = true;
                this.state = normal;
                break;

              // ESC > Normal Keypad (DECPNM).
              case '>':
                this.log('Switching back to normal keypad.');
                this.applicationKeypad = false;
                this.state = normal;
                break;

النظر في ما من المرجح أن يقودنا DECPAM و DECPNM إلى إجابة. أيضًا إذا كان هناك اختلاف مع DEC K PAM و DEC K PNM.

Xterm.js التمرير باستخدام oh my zsh يعمل الآن ، مع هذا الفرع

أهلا. تم العثور على هذا الموضوع من الخطأ ذي الصلة على Oh My Zsh.

النظر في ما من المرجح أن يقودنا DECPAM و DECPNM إلى إجابة. أيضًا إذا كان هناك اختلاف مع DECKPAM و DECKPNM.

أعتقد أن DECPAM و DECPNM مجرد أخطاء إملائية لـ DECKPAM و DECKPNM. فن الإستذكار هما "وضع تطبيق لوحة مفاتيح DEC" و "الوضع العادي للوحة مفاتيح DEC".

تعمل أوضاع لوحة مفاتيح التطبيق على تغيير تسلسل الأحرف الذي ترسله لوحة مفاتيح المؤشر و / أو مفاتيح لوحة المفاتيح الرقمية استجابةً للضغط على المفاتيح. هناك نوعان (أو أكثر) من أوضاع لوحة المفاتيح المميزة التي يمكن ضبطها إما على "تطبيق" أو "عادي": لوحة المفاتيح الرقمية ولوحة مفاتيح المؤشر. تعدل الخصائص applicationKeypad و applicationCursor التسلسلات المرسلة بواسطة بعض المفاتيح ، وهو ما يبدو مناسبًا.

يبدو لي أنه قد يكون هناك خطأ في مفتاحي Home and End ، على الرغم من ذلك. تم تعديل سلوكهم "مفاتيح وظائف نمط الكمبيوتر" في مستند مرجعي xterm هذا .) أعتقد أن هذا يعني أنه يجب التحكم فيها بواسطة applicationCursor بدلاً من applicationKeypad .

بغض النظر ، من المدهش بالنسبة لي أن يؤثر وضع لوحة المفاتيح على سلوك عجلة تمرير الماوس. (هذا هو التمرير الذي يتحدث عنه OP ، حول ، أليس كذلك؟) ربما يكون الإصلاح بسيطًا مثل إزالة هذا الاختيار if (self.applicationKeypad) return; من معالج عجلة تمرير الماوس.

لا يمكنني الوصول إلى zsh في الوقت الحالي ، لذا لا يمكنني اختبار ذلك.

يمكنك اختبار هذا السلوك تحت bash أو قذائف أخرى عن طريق القيام بـ tput smkx . هذا يعادل zsh echoti . لكن اعلم أنه بموجب معظم تعريفات معلومات المصطلحات ، يرسل smkx التسلسلات لكل من لوحة مفاتيح مؤشر التطبيق وأوضاع لوحة المفاتيح الرقمية للتطبيق ، لذا فأنت لا تختبرها بشكل مستقل إذا قمت بذلك بهذه الطريقة. لاختبارها بشكل مستقل (على سبيل المثال ، إذا كنت تريد التحقق من الوضع الذي كان يتحكم في سلوك Home / End) ، فستحتاج إلى تكرار تسلسلات الهروب هذه بشكل منفصل. (لا أتذكر كيف أفعل ذلك من فوق رأسي).

أعتقد أن هذا هو نفس السبب الجذري لسبب عدم عمل التمرير في vim والذي يحدد أيضًا DECKPAM .

باتباع مواصفات الماوس xterm ، لا يتم تعديل إجراءات الماوس بواسطة DECKPAM أو DECKPNM. هل يعرف أحد سبب وجود if (self.applicationKeypad) return; في معالج تمرير الماوس على الإطلاق؟

jerch ، نعم ، لقد بدأت في التفكير أيضًا ، هناك مجموعة من القراءة أريد أن أقوم بها في # 194 لإصلاح هذه الأنواع من المشكلات أخيرًا.

أعتقد أن لدي المزيد من المدخلات لتقديمها هنا.

ربما يكون الإصلاح بسيطًا مثل إزالة ذلك إذا عاد (self.applicationKeypad) ؛ تحقق من معالج عجلة تمرير الماوس.
apjanke هذا لن يعمل ويجب ألا يعمل في الواقع. يوجد معالج الحدث هذا للسماح بالتمرير في تطبيقات وضع النص البسيط مثل bash ، والتي تم تعيين applicationKeypad على false (راجع للشغل. يبدو مفيدًا جدًا لتوثيق هذا بشكل أفضل).

بالإضافة إلى ذلك ، حتى إذا أزلنا هذا ، فسيؤدي ذلك إلى مكالمة term.scrollDisp(1) ، والتي لن تفعل شيئًا عندما يكون تطبيق مثل vim مفتوحًا ، حيث term.ydisp و term.ybase كلاهما 0 .

يجب أن يتم التعامل مع هذا على الأرجح في معالج الحدث السابق.

Xterm.js التمرير باستخدام oh my zsh يعمل الآن ، مع هذا الفرع

richarddavenport هل

parisk نعم ، إنه يعمل دون أي تغيير في xterm.js.

ربما يكون الإصلاح بسيطًا مثل إزالة هذا الاختيار if (self.applicationKeypad) return; من معالج عجلة تمرير الماوس.
apjanke هذا لن يعمل ويجب ألا يعمل في الواقع. يوجد معالج الحدث هذا للسماح بالتمرير في تطبيقات وضع النص البسيط مثل bash ، والتي تم تعيين applicationKeypad على false (راجع للشغل. يبدو مفيدًا جدًا لتوثيق هذا بشكل أفضل).

ألا ينبغي أن يكون هذا السلوك مجرد وظيفة لوضع تعقب الماوس ، والشاشة البديلة ، وأوضاع التمرير البديل ، وليس أوضاع لوحة مفاتيح التطبيق الرقمية / المؤشر؟ OP يستخدم zsh ، والذي يشبه bash أكثر من vim : إنه تطبيق نصي بسيط يستخدم الشاشة الرئيسية ولا يوفر دعم التمرير الخاص به ، لذلك يعتمد على المحطة للقيام بالتمرير. لكن بعض هذه البرامج النصية البسيطة ، وخاصة zsh ، قد تستمر في تمكين وضع Application Keypad حتى يتمكنوا من القيام بربط المفاتيح المحمولة باستخدام تعريفات terminfo ، والتي عادةً ما تتضمن فقط تسلسل أحرف وضع التطبيق.

parisk أنا ثانيًا ما يقوله Apjanke - لماذا يجب أن تتداخل إعدادات وضع لوحة المفاتيح على الإطلاق مع سلوك الماوس؟ لا تذكر مواصفات xterm الرسمية أيًا من هذا ، وبالتالي فإن تطبيق نموذج متوافق مع xterm قد لا يكون له مثل هذا القيد. ربما أفتقد شيء هنا.
ستسجل التطبيقات الطرفية "عالية المستوى" مثل midnight Commander تتبعًا صريحًا للماوس - بالنسبة لتلك التطبيقات Xterm تقوم فقط بتعطيل المعالج الافتراضي ويتم التعامل مع الأحداث بواسطة تطبيق المحطة الطرفية نفسه (مما قد يؤدي إلى تعطيل التمرير - الأمر متروك للتطبيق)

علاوة على ذلك ، يتم استخدام مفتاح الشاشة البديل (DECSET 1047) للإشارة إلى سلوك طرفي مختلف - يأتي المخزن المؤقت للشاشة العادي (منخفض 1047) مع المخزن المؤقت للتمرير بينما لا يحتوي المخزن البديل (ارتفاع 1047) على أي شيء. يتم استخدام هذا الأخير من قبل جميع تطبيقات اللعنات ، و vim ، و emacs وغيرها من التطبيقات الطرفية الأكثر تعقيدًا التي تستخدم الجهاز كقماش (تعتمد معظم التطبيقات بشكل كبير على معلومات المصطلح). بالنسبة لتلك التطبيقات ، لا يوجد تمرير في المحطة الطرفية. يمكنك اختبار ذلك بنفسك عن طريق تشغيل vim أو emacs في xterm - لا يمكنك العودة إلى محتوى المحطة السابق. بعد إغلاق التطبيق والعودة إلى الوضع العادي لواجهة shell ، يتم "تمكين" التمرير مرة أخرى.
من الناحية الفنية ، تحتفظ Xterm بمخازن مؤقتة منفصلة للشاشة لتحقيق ذلك. DECSET 1047 يبدل بينهما فقط.

هناك أيضًا تطبيقات تقوم بالرسم الأكثر تقدمًا على الشاشة العادية (مثل man ، أعلى) ولا تسجل تتبع الماوس. لا يزال xterm قابلاً للتمرير لهؤلاء ومحتواهم موجود فقط في نهاية المخزن المؤقت للإخراج.

ما أسهل "حل بديل" متاح قبل معالجة ذلك بطريقة أكثر تفصيلاً؟

ksnyde ربما يكون هذا هو الأسهل: https://github.com/Microsoft/vscode/issues/7817#issuecomment -229069151. لم أجربها شخصيًا رغم ذلك.

ربما يكون هذا هو الأسهل: Microsoft / vscode # 7817 (تعليق). لم أجربها شخصيًا رغم ذلك.

لسوء الحظ ، سيؤدي ذلك إلى كسر روابط المفاتيح الأخرى التي تعتمد على zle_line_init . يجوز لك أو لا تستخدم روابط المفاتيح هذه ، لذلك قد تهمك أو لا تهمك.

هناك OMZ PR مفتوحًا قمت بوضعه لإسقاط التبعية zle_line_init / [sr]mkx والتمسك بوضع

هذا هو ، إذا كنت تستخدم Oh My Zsh. إذا كنت تستخدم أحد توزيعات Linux التي تهيئ zle_line_init لاستخدام [sr]mkx في ملفات تكوين النظام الخاصة بهم ، فستحتاج إلى إعادة تعريف zle_line_init في ~/.zshrc الخاص بك

function zle-line-linit() {
  # NOP
}

(قد يؤدي ذلك إلى كسر روابط المفاتيح الأخرى التي تعتمد على وضع لوحة مفاتيح التطبيق.)

بالنسبة لتلك التطبيقات ، لا يوجد تمرير في المحطة الطرفية. يمكنك اختبار ذلك بنفسك عن طريق تشغيل vim أو emacs في xterm - لا يمكنك العودة إلى محتوى المحطة السابق.

اختلاف بسيط ، لكن هذا ليس صحيحًا تمامًا: في xterm ، على الأقل بعض إصداراته ، إذا قمت بتشغيل vim ، فإنه يتحول إلى الشاشة البديلة ، ولكن لا يزال بإمكانك التمرير للخلف ومشاهدة المحتويات السابقة للمخزن المؤقت (طالما أن المخزن المؤقت يحتوي على أكثر من شاشة من المحتوى) ، طالما أنك لم تقم بتمكين معالجة أحداث الماوس في vim . إذا كنت :set mouse=a في vim ، فستتلقى أحداث الماوس ، ولن يتم تمرير المحطة استجابةً لها. ربما لا يرى معظم المستخدمين السلوك السابق لأنهم قاموا بإعداد .vimrc لتمكين معالجة أحداث الماوس تلقائيًا. أعتقد أن هذا يشير إلى أن سلوك تمرير عنصر واجهة المستخدم على مستوى المحطة يتم التحكم فيه عن طريق معالجة أحداث الماوس ، وليس عن طريق وضع الشاشة البديل.

شكرًا للتوضيح apjanke - لتقليد سلوك xterm تمامًا ، يجب مراجعة معالجة مخزن التمرير المؤقت و DECSET 1047 أولاً IMO.

Tyriar ، من فضلك علمني لماذا هناك حاجة إلى 1b886a44.
هل تريد فقط إخفاء شريط التمرير العمودي؟
لقد لاحظت سلوك xterm على نظام التشغيل Linux لبعض الوقت ، واعتقدت أنه يجب إسقاط 1b886a44.

ayapi الذي يتم إرجاع الالتزام في https://github.com/sourcelair/xterm.js/pull/287

سيؤدي ذلك إلى ظهور شريط التمرير ولكن لن تتفاعل المحطة الطرفية مع عجلة الماوس.

FWIW ، أعتقد أن هذه حالة انحراف Xterm.js عن سلوك xterm العادي ، وليست مشكلة Oh My Zsh ، ويجب إغلاق هذا الخطأ. إذا كان OMZ يوفر رقاقة توافق له ، فيجب أن يقتصر على مكون إضافي.

apjanke لذا فأنت توافق على العلاقات العامة التي طرحتها للتو؟ # 289

نعم ، أوافق على https://github.com/sourcelair/xterm.js/pull/289. "وضع التطبيق" كما تمت مناقشته هنا هو مجرد مفتاح وضع لوحة المفاتيح ؛ يجب ألا يتأثر سلوك الماوس به ، لذا يجب السماح بأحداث العجلة.