Xterm.js: استقرار IParser API

Tyriar يبدو جيدًا بالنسبة لي ، باستخدام register بدلاً من add .

حول النهايات السائبة - حسنًا ، لا أحب حقيقة أن لدينا حدًا صارمًا على OSC / DCS ، لكن هذا ليس مصدر قلق حقًا أجهزة الصراف الآلي. إذا كان علينا دعم تسلسل الطول العشوائي في المستقبل ، فيمكننا دائمًا كشف الواجهات المقسمة أيضًا.
sdegutis كان لديه طلب لمعالجة معلمات التسلسل الفردية هنا ، لكنني أعتقد حاليًا أنه لا ينبغي لنا الدخول في أعمال نشر لاحقة. بالنسبة لمعظم التسلسلات ، يكون للمعلمات معنى مقترن بالموضع ، وبالتالي ليس من المنطقي السير في هذا الطريق. التسلسلات التي تحتوي على معلمات تكديس بحرية مثل DECSET أو SGR ، لا يزال من الممكن ربطها بمعالج مخصص والتعامل فقط مع المعلمات التي تهتم بها.

الكل في الكل أعتقد أن API تعمل بشكل رائع حتى الآن.

حسنًا ، لا أحب حقيقة أن لدينا حدًا صارمًا على OSC / DCS ، لكن هذا لا يمثل مصدر قلق حقيقيًا لأجهزة الصراف الآلي

هل يمكنك أن توضح قليلاً ما هو الحد؟

sdegutis أنا مهتم إذا كان لديك المزيد من التعليقات بعد اللعب باستخدام واجهة برمجة التطبيقات.

Tyriar الحد هو حد بسيط بسيط أقصى طول للحمولة الصافية يبلغ 10 ميغا بايت. أي تسلسل يتجاوز ذلك سيتم ابتلاعه بصمت.

اهلاTyriar و jerch كيف الحال. لذلك كانت حالة الاستخدام الخاصة بي هي أنني أردت فقط إنشاء التقاط اتصال على الشاشة المتغيرة ?1049h و ?1049l لميزة "تراكب عنصر واجهة المستخدم" الأساسية الخاصة بي ، لأنني مضطر لإخفاء تراكب حاوية عنصر واجهة المستخدم المغادر للشاشة المحددة عند التبديل بعيدًا عنها ، وإظهار حاوية عناصر واجهة المستخدم القادمة للشاشة / المخزن المؤقت / الشيء الحالي الجديد (ما هو الاسم الصحيح لهذه الأشياء؟).

الآن علي أن أفعل هذا:

  term.parser.addCsiHandler({ prefix: '?', final: 'h' }, (params) => {
    if (params.includes(1049)) {
      altScreen = true;
      toggledAltScreen();
    }
    return false;
  });

  term.parser.addCsiHandler({ prefix: '?', final: 'l' }, (params) => {
    if (params.includes(1049)) {
      altScreen = false;
      toggledAltScreen();
    }
    return false;
  });

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

• مطابقة سلسلة كاملة ، مثل { whole: '?1049h' } - سيظل هذا بحاجة إلى ردتي نداء ، ولكن قد لا يمثل ذلك مشكلة. لست متأكدًا من الأداء ولكن لا أفترض أنه يجب أن يكون أسوأ نظرًا لأن لديك طول السلسلة بالكامل ويمكنك تشغيل ذلك بسرعة قبل إجراء مقارنة السلسلة.

• مطابقة regex مثل { regex: /?1049(h|l)/ } - ربما يكون هذا أداء أسوأ حيث لا يمكنك فقط تشغيل طول السلسلة في وقت مبكر ، لذلك عليك اختبار regex في كل مرة تحصل فيها على حرف جديد ، إلا إذا يعمل بنفس الطريقة التي يعمل بها whole وسيحاول فقط المطابقة بعد الانتهاء من التسلسل.

هذه هي أفضل نسخة يمكنني التفكير فيها ، لحالة الاستخدام المحددة للغاية الخاصة بي:

  // not sure the \? is right, forgot how JS regex works, but ignore that
  term.parser.addCsiHandler({ regex: /\?1049(h|l)/ }, (match) => {
    altScreen = match[1] === 'h';
    toggledAltScreen();
    return false;
  });

الاستخدام الفردي لـ Tyriar VS Code سيعمل أيضًا بشكل جيد مع نهج regex ، باستخدام { regex: /H$/ } . وربما يكون بنفس الأداء ، مع كونه أكثر مرونة. في الواقع ، قد لا تحتاج حتى إلى خريطة خيارات بعد الآن بالبادئة / اللاحقة / إلخ ؛ يمكن أن تكون الوسيطة الأولى مجرد regex.

sdegutis Thx للتعليق. بعض الملاحظات من جانبي:

الآن علي أن أفعل هذا: [.. code]

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

حول regexp:
لن تعمل فكرة regexp لسبب بسيط - يعمل المحلل اللغوي على نقاط كود UTF32 وليس سلاسل (ولست حريصًا على كتابة محلل regexp لهذا lol). يتم ترجمة معرّف الوظيفة إلى أرقام تشكل مفتاح جدول انتقال للمعالجات في المحلل اللغوي. هذا مستوى منخفض جدًا من معالجة البيانات ، ولكن الطريقة الوحيدة للحفاظ على سرعة المحلل اللغوي (في الواقع ، لا يزال المفتاح -> القفزة المستهدفة مكلفًا للغاية).

ملاحظة أكثر عمومية حول تسلسل regexp و ANSI - يكاد يكون من المستحيل فهم ذلك بشكل صحيح. هناك ببساطة عدد كبير جدًا من ifs and elses في حالة الإعراب والتي يجب عليك سحبها إلى regexp نفسه. أعتقد أن جميع الحزم المستندة إلى regexp التي تحاول تجريد التسلسلات من البيانات تفهم هذا الخطأ. للحصول على DECSET 1049 بشكل صحيح بواسطة regexp سيبدو مثل:

/(([\x1b][\[])|[\x9b])[?][0-9;]*?1049((h|l)|(;[0-9;]+?)(h|l))/

(لا يزال هذا خطأً قليلاً ولكن من يهتم ، أعتقد أنك حصلت على وجهة نظري ...)

لذا لا يعمل regexp imho هنا لهذين السببين.

من المنطقي ، شكرا على المعلومات.

ماذا عن السماح للمعلمات بأن تكون عددًا عشوائيًا من البايت ، على سبيل المثال { params: '1049' } ؟ ولكن إذا كان هذا أيضًا غير فعال جدًا ، فأنا بخير لإبقائه كما هو ، لأن ذلك لن يكون سوى تحسين طفيف (جدًا) مقارنة بما لدي الآن.

حسنًا ، لا ينقسم المحلل اللغوي إلى تسلسلات ، بل يعمل على التسلسلات ككل (مرة أخرى لأسباب تتعلق بالأداء). لذا فإن المحلل اللغوي سوف يقوم بتشغيل المعالج لكل هذه:

• CSI ? h -> بارام: [0]
• CSI ? 1 ; 2 ; h -> param: [1، 2، 0]
• CSI ? 99999999999999999999 h -> بارام: [2 ^ 31 - 1] (مثبت بـ int32_t)

Ofc سيكون من الممكن إجراء تقطيع إلى معلمات مفردة بخطوة تالية ، لكن الأمر ببساطة لا يستحق ذلك (كما كتبت أعلاه): معظم التسلسلات تدرك المعلمات الخاصة بها ، وبالتالي لا يمكن تقطيعها على الإطلاق. يمكن للآخرين مثل DECSET دمج المعلمات بحرية ولا تزال صالحة ، ويمكن تقطيع تلك المعلمات فقط ، ولكنها ببساطة لا تستحق الجهد المبذول في أجهزة الصراف الآلي.

بعض المعلومات الأساسية عن هذا: يمكن رؤية التسلسل كدالة توفرها المحطة ، حيث تترجم المعلمات إلى وسيطات دالة ، وبالتالي يترجم CSI ? 1;2;3;4;5 h إلى:

• الوظيفة: بادئة "؟" (DEC خاص) + نهائي "h" (SM) -> DECSET
• وظيفة استدعاء مع المعلمات: for (p in params) DECSET p;

نحن نقدم فقط واجهة الوظيفة ، وبالتالي تحصل على جميع الحجج.

أعتقد أن مشكلة sdegutis يمكن حلها بمثال مناسب في xterm.d.ts ، ما انتهى به الأمر هو كيفية استخدامها بشكل صحيح (على الرغم من أن العائد الحقيقي قد يكون أفضل في if؟).

Tyriar حسنًا أيضًا أن المفتاح params أربكني لأنني لم أكن متأكدًا مما يعنيه بالبايت في البداية ، ويرجع ذلك جزئيًا إلى سوء فهمي لأشياء DECSET. إذا نظرنا إلى الوراء ، فأنا متأكد من أنني إذا أردت التقاط 1049 ، فعندئذٍ بما أن params يأخذ أي سلسلة فرعية ، حتى اثنين ، فيمكنني فقط تمرير 10 أو 04 أو 49 وسيحد بشكل أساسي عمليات الاسترجاعات التي أحصل عليها لمطابقة هذه السلسلة الفرعية (مما يعني أن 1000 و 49 سيتطابقان). حسنًا ، أعتقد أن مجرد مثال بسيط في المستندات سيوضح. ليس لدي مشكلة مع API كما هي.

Tyriar أيضًا عودة صحيحة في إذا كانت ستوقف xterm.js من تبديل المخازن المؤقتة بالنسبة لي ، كنت أرغب في تبديل المخازن المؤقتة كالمعتاد ، أردت فقط التقاط هذا الحدث والقيام بأشياء إضافية فوقه.

sdegutis ، حسنًا ، أنت تستخدمه تمامًا كما استخدمته آنذاك. مجرد الاستماع وليس لمس / إلغاء أي شيء 🙂

... يمكن حلها بمثال مناسب في xterm.d.ts ...

نعم ، يمكن أن يكون جزءًا من تنظيف الخطافات والإزالة التجريبية.

على الرغم من أن العائد صحيح قد يكون أفضل في إذا؟

محذوف (مجاب بالفعل: ابتسامة :).

sdegutis ، حسنًا ، أنت تستخدمه تمامًا كما استخدمته آنذاك. مجرد الاستماع وليس لمس / إلغاء أي شيء 🙂

نعم! كل ما كنت أتحدث عنه حقًا في أي من هذه الخيوط يعمل من أجل ميزة "إضافة أدوات DOM تعسفية إلى المحطة". في هذا الموضوع ، عندما تبدأ vim ، يجب إخفاء عنصر DOM الموجود في المخزن المؤقت الرئيسي ، وإظهاره مرة أخرى عند إنهاء vim ، لذلك كنت بحاجة إلى ربط لذلك.

فكرتي الوحيدة هي أننا يجب أن نفكر في الفعل (إضافة ، تسجيل ، إلخ) ومعرفة أين نريد أن نذهب. أعتقد أن add يبدو غريبًا بعض الشيء بدون remove ، يستخدم VS Code register للموردين / المعالجات / المصانع:

أنا شخصياً أعتقد أن add جيد.

يبدو أن sdegutis يجب أن تكون الزخارف العازلة مرتبطة بمخزن مؤقت معين حتى لا تحتاج إلى التوفيق بينها بهذا الشكل.

Tyriar نعم إذا كانت ميزة مضمنة ، فستكون هناك حاجة ماسة إليها. تخيل التحول إلى vim أثناء عرض أي زخرفة على الشاشة. سيتعين عليها الاختباء حتى إنهاء vim أو ctrl-z (SIGTSTP) ، أليس كذلك؟

👍 انتقلت المناقشة إلى https://github.com/xtermjs/xterm.js/issues/1852#issuecomment -562667063

هناك شيء واحد يجب مراعاته في واجهة برمجة التطبيقات هذه: لنفترض أنك حصلت على CSI ? 1;2;3;4;5 h مثل المثال الأصلي لـ jerch . قد ترغب في الرد على الرقم 3 ومنع السلوك الافتراضي لذلك ، لكن اتركه لـ 1،2،4،5. لذلك ربما يجب أن يؤدي هذا إلى إرجاع مجموعة من الأحداث التي تريد أن تستمر في محاولة التعامل معها؟

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

أو لماذا لا ترسل في الوقت الحالي الذي عادة ما تستدعي المعالج؟ لماذا التعامل مع مجموعة الرموز ككل؟ على سبيل المثال ، إذا تم استدعاء CSI ? 1049 ; 2004 h ، فإن الكود يقوم بالفعل بتشغيل وظيفة داخلية للتعامل مع 1049 ، ثم واحدة للتعامل مع 2004. لذلك في مواقع الاتصال هذه (أو بالأحرى فوقها) لماذا لا تبحث فقط عن وظيفة موجودة في رد الاتصال مجموعة مصفوفة؟ هل هذا ممكن؟ هل سيكون غير فعال للغاية؟ عفوا إذا كان سؤال غبي.

حسنًا ، لم يكن الأمر مجرد مشكلة حتى الآن. تحقق للتو من مستندات xterm - من بين 90 أمرًا مدرجًا في CSI ، يمكن تكديس 14 أمرًا فقط بدون أي معنى موضعي. حاليًا نحن ننفذ 5 فقط من هؤلاء (و 50 في المجموع). لا يمكن تقسيم كل الآخرين (بسبب المعنى الموضعي) أو لديهم صفر / واحد بارامترات.

أو لماذا لا ترسل في الوقت الحالي الذي عادة ما تستدعي المعالج؟ لماذا التعامل مع مجموعة الرموز ككل؟

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

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

فهمت ، شكرا على المعلومات. سأتوقف عن الأسئلة الغبية الآن :) تعمل واجهة برمجة التطبيقات الحالية بشكل جيد بما يكفي بالنسبة لي.

لا يوجد غبي ... ، أيا كان - أعترف أن واجهة الخطافات يجب أن تحصل على مستندات أفضل ، وليس من الواضح كيفية استخدامها أجهزة الصراف الآلي.

Tyriar لتلخيص هذا هنا - من جانبي يبدو هذا جاهزًا للحصول على "رسمي". سنقوم بمعالجة مشكلة التوثيق بشكل منفصل بمقال حول التسلسلات والخطافات على موقع الويب.