Xterm.js: API للتحقق مما إذا كانت الشاشة البديلة نشطة

Eugeny ما الذي تحتاجه بدافع الفضول؟

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

أنا أتطلع إلى تعطيله فقط طالما أن الشاشة البديلة نشطة

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

ربما تكون إضافة isNormalBuffer و isAltBuffer إلى IBuffer كافية؟

سيكون من الجيد أيضًا أن يكون لديك حدث مثل terminal.onBufferActivate((buffer: IBuffer) => void ) للتفاعل ديناميكيًا مع تغييرات المخزن المؤقت.

ربما ينبغي لنا أيضًا أن ننتهز هذه الفرصة لمخزن مساحة الاسم كما فعلنا مع المحلل اللغوي ، شيء من هذا القبيل؟

interface buffer {
  normal: IBuffer
  alt: IBuffer
  active: IBuffer
  onDidChangeBuffer: IEvent<IBuffer>
}

Tyriar نعم هذا يبدو جيدًا. لذا فإن التحقق مما إذا كان المخزن المؤقت العادي نشطًا سيكون تعبيرًا مثل terminal.buffer.active === terminal.buffer.normal ؟ أم يجب علينا أيضًا تقديم طريقة ملائمة لها إما على واجهة buffer أو IBuffer ؟

أعتقد أن الحصول على IBuffer.type: 'normal' | 'alt' سيكون أفضل ما في العالمين؟

مجرد تنبيه بسيط - يجب أن نحرص على تقديم الكثير من الاستبطان المتزامن للحالة لسبب بسيط - سينتهي الأمر بـ ppl بمحاولة القيام بأشياء بناءً على ذلك ولكن في الغالب يتجاهل حالة المخزن المؤقت للإدخال الحالي ، والذي قد يغير الأشياء في أي وقت مرة أخرى. ( Tyriar هل تتذكر هذه المشكلة المتعلقة بمحاولة شخص ما كتابة واجهة lisp المحلية؟ من الصعب جدًا اكتشاف مشكلات إلغاء المزامنة سينتج عن ذلك.)

أو ربما يجب أن نكون أكثر وضوحًا بشأن ذلك في مستند API ، أي جزء متزامن / غير متزامن ...

jerch أعتقد أن ملاحظة على write ستساعد هذه المشاكل. ستكون محاولة معالجة هذه المشكلة مع المستندات أفضل من عدم تقديم شيء كهذا.

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

Tyriar serialize-addon تحتاج أيضًا إلى طريقة لقراءة المخزن المؤقت البديل. بخلاف ذلك ، من الصعب جدًا تنفيذ مشغل جلسة تشغيل المحطة الطرفية حتى أداة مشاركة الجلسة الطرفية التي تسمح لأي شخص بالانضمام في أي وقت (لقد وجدت أن امتداد المشاركة المباشرة لـ vscode يدعم بالفعل مشاركة المحطة ، ولا أعرف كيف يعمل بدلاً من إرسال جميع مخرجات المحطة البداية)

@ JavaCS3 هل هذه حقا مشكلة؟ سيحصل Imho المتسلسل دائمًا على نفس المخزن المؤقت الذي يراه المستخدم كإخراج للشاشة في وقت التسلسل. علاوة على ذلك ، تستخدم التطبيقات عادةً DECSET 1049 هذه الأيام ، والتي ستعمل دائمًا على تنظيف Altbuffer. وبالتالي ، حتى إذا كان Altbuffer لا يزال يحتفظ بالبيانات ، فسيُنظر إليه على أنه بقايا من جلسة altbuffer السابقة.

يحتاج المسلسل Imho فقط إلى الاهتمام بمخزن مؤقت واحد في وقت معين. لاحظ أن التشغيل الحقيقي لن يكون ممكنًا مع البرنامج المساعد التسلسلي ، لذلك سيتعين عليك تسجيل بيانات الإدخال. (Serialize plugin - لقطة في وقت معين ، تشغيل - استعادة الحالات بمرور الوقت ؛ فرق كبير).

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

jerch بالنسبة لي ، حالة الاستخدام هي العكس. أريد فقط إجراء تسلسل للمخزن المؤقت العادي ، لذلك عند استعادة محطة طرفية بعد إعادة تشغيل التطبيق ، أريد فقط استعادة محفوظات المخزن المؤقت العادي. في الوقت الحالي ، أستخدم الاختراق عن طريق استدعاء terminal._core.buffers.activateNormalBuffer() قبل تشغيل الملحق التسلسلي. سيكون وجود واجهة برمجة تطبيقات عامة لهذا أفضل بالتأكيد.

mofux هل تريد إعطاء serialize المخزن المؤقت كوسيطة؟ لكن أليس هذا ممكنًا بالفعل مع اقتراح Tyriar أعلاه (بعد تمديد التسلسل بهذه الطريقة)؟ ربما أفتقد بعض النقاط ...

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

jerch الفكرة الأساسية لمشغل التشغيل الطرفي هي مثل ما تقوله ، (أنشئ لقطة واحدة تلو الأخرى واملأ الفراغ بين اللقطات بفرق تزايدي) ولكن هناك مشكلة إذا كان وقت إنشاء اللقطة أثناء البديل نشطًا ثم الفروق المتزايدة التالية تحتوي على DEC 1049 (Use Normal Screen Buffer and restore cursor) . ستكون هناك فوضى لأن المخزن المؤقت العادي لم يتم إجراء تسلسل له بعد. هذا وجهة نظري. بخلاف ذلك ، يجب أن أتأكد من أن إنشاء اللقطة يكون قبل DECSET 1049 . لكنني أعتقد أنه سيكون من المفيد أن أتمكن من الوصول مباشرة إلى كل من المخزن المؤقت العادي والمخزن البديل.

(خارج الموضوع)
سأستخدم asciinema لمساعدتي في تسجيل المخزن المؤقت الطرفي بدلاً من إضافة ملحق جديد إلى xterm.js. ملف تسجيل Asiinema مثل

[0.031006, "o", "\u001b]0;mat@mat-mint: ~/Documents/term-tris\u0007\u001b[01;32mmat@mat-mint\u001b[00m:\u001b[01;34m~/Documents/term-tris\u001b[00m$ "]
[0.739447, "o", "s"]
[0.843387, "o", "u"]
[0.939383, "o", "d"]
[1.051685, "o", "o"]
[1.147569, "o", " "]
[1.291866, "o", "p"]
[1.419392, "o", "y"]
[1.578995, "o", "t"]
[1.635077, "o", "h"]
[1.699073, "o", "o"]
[1.810955, "o", "n"]
[1.891268, "o", "3"]
[1.962887, "o", " "]
[2.083119, "o", "m"]
[2.202915, "o", "a"]
[2.315119, "o", "i"]
[2.394943, "o", "n"]
[2.603245, "o", "."]
[2.810757, "o", "p"]
[2.906992, "o", "y"]
[3.034495, "o", "\r\n"]
[3.04091, "o", "[sudo] password for mat: "]
[5.266162, "o", "\r\n"]
[5.369433, "o", "\u001b[?1049h\u001b[22;0;0t\u001b[1;24r\u001b(B\u001b[m\u001b[4l\u001b[?7h\u001b[?1h\u001b="]
[5.402342, "o", "\u001b[39;49m\u001b[?1h\u001b=\u001b[?25l"]
[5.402543, "o", "\u001b[?1000h\u001b[39;49m\u001b[37m\u001b[40m\u001b[H\u001b[2J"]

الغرض من إنشاء مشغل تشغيل طرفي هو أن المشغل الطرفي لـ asciinema مكتوب في ClojureScript والذي أعتقد أنه من الصعب على الأشخاص المساهمة فيه. لذلك قررت أن أكتب نسختي الخاصة باستخدام xterm.js

لكنني أعتقد أنه سيكون من المفيد أن أتمكن من الوصول مباشرة إلى كل من المخزن المؤقت العادي والمخزن البديل.

لكن هذا ما يدور حوله اقتراح

يبدو أن Asciinema يقوم بتتبع زمني لإخراج pty. نعم ، imho الطريقة الوحيدة للحصول على إعادة تشغيل صحيحة. تتمثل ميزة البرنامج المساعد التسلسلي هنا ، في أنه يمكنك بدء إعادة التشغيل من أي لقطة تتجاهل إخراج pty الأقدم. بالمناسبة ، يمكنك إنشاء مثل هذا التتبع الزمني بسهولة تامة ، بشكل تخطيطي:

let recording = false;
const recordedData = [];
function overloadedWrite(chunk, cb) {
  term.write(chunk, () => {
    if (recording) recordedData.push([Date.now(), 'input', chunk]);
    if (cb) cb();
  });
}
// replace term.write invocation with overloaded function
...
// initial snapshot, also activate recording
const initialData = addon.serialize(normal_buffer_as_arg);
// maybe 2nd call with altbuffer (if thats the active atm)
recording = true;
// more states need to be serialized here, like initial DEC private flags
const internalStates = ...
...
// stop recording
recording = false;

// --> final replay from snapshot is initialData + internalStates + recordedData

هذه مجرد فكرة تقريبية ، لا تزال هناك أجزاء مفقودة مثل تغيير حجم التسجيل. وإذا كررت اللقطة بينهما وجمعت التسجيل تحت لقطة ، فستحصل أساسًا على "إطارات متزامنة" كما هو الحال في برامج ترميز mpeg ، والتي تسمح لاحقًا بالتخطي / البحث.

jerch أعتقد أن ردي الأول https://github.com/xtermjs/xterm.js/issues/2694#issuecomment -584537861 مضلل قليلاً. يمكن أن يحل اقتراح @ Tyriar مشكلتي أيضًا. أريد أن أوضح لماذا نحتاج إلى الوصول إلى مخزن مؤقت بديل في حالة المستخدم الخاصة بي. آسف على تعبيري الضعيف.

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

jerch أعتقد أنه كان هناك بعض سوء الفهم 🤗 كل ما أحتاجه هو طريقة نظيفة لإخبار الملحق التسلسلي أي المخزن المؤقت للتسلسل. أعتقد أن واجهة برمجة التطبيقات التي اقترحها Tyriar ستزودها بواجهة برمجة التطبيقات المطلوبة للقيام بذلك.

كل ما أحتاجه هو طريقة نظيفة لإخبار الملحق التسلسلي بالمخزن المؤقت الذي يجب إجراء التسلسل.

هذا ما أريده في النهاية أيضًا ، ضع في اعتبارك السيناريو التالي:

1. افتح VS Code
2. افتح Terminal
3. افتح vim
4. أعد تشغيل رمز VS
5. يتم فتح محطة ، واستعادة المخازن المؤقتة العادية والمخازن البديلة

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

توصلت للتو إلى حالة الاستخدام الخاصة بي للتحقق مما إذا كان المخزن المؤقت البديل نشطًا: https://github.com/microsoft/vscode/issues/90838

يمكنني بالفعل تحقيق هذا الرمز terminal.buffer.active.type أو فاتني شيء؟

يمكنني بالفعل تحقيق هذا الرمز terminal.buffer.active.type أو فاتني شيء؟

لأنه تم دمج 2713 #

شكرا على النتوء 🙂