Xterm.js: يؤدي التشغيل الواضح في المحطة الطرفية إلى إزالة محتوى منفذ العرض من المخزن المؤقت بدلاً من إخفائه

gnome-terminal به أخطاء في هذا الصدد ، فهو يزيل العديد من الصفوف من بداية المخزن المؤقت ، وليس منفذ العرض القديم.

فيما يلي مواصفات الإشارة المستلمة (2):

ED – Erase In Display

ESC [ Ps J  default value: 0
This sequence erases some or all of the characters in the display according to the parameter. Any complete line erased by this sequence will return that line to single width mode. Editor Function

Parameter   Parameter Meaning
0   Erase from the active position to the end of the screen, inclusive (default)
1   Erase from start of the screen to the active position, inclusive
2   Erase all of the display – all lines are erased, changed to single-width, and the cursor does not move.

http://www.vt100.net/docs/vt100-ug/chapter3.html

قد يكون الشيء الصحيح هو مسح كل شيء تمامًا مثل xterm .

فهل علينا المضي قدمًا في إغلاق هذه القضية وترك سلوك التنظيف كما هو؟

parisk حسنًا ، يبدو الأمر وكأنه خطأ بالنسبة لي ، ربما يكون مجرد القيام بما تفعله xterm أفضل بالنظر إلى أن هذا هو ما يحاول هذا محاكاته؟

حسنًا ، أجرى بعض الاختبارات. أعتقد أن اقتراحك "تحويل الصفوف لأعلى" بدلاً من إزالتها من المخزن المؤقت يوفر أفضل تجربة مستخدم ، حتى لو لم تكن متوافقة مع xterm بنسبة 100٪.

لقد واجهت هذا للتو مع: https://github.com/Microsoft/vscode/issues/19934

أرغب في لصق حالة الاستخدام هنا للنظر فيها:

حالة الاستخدام الخاصة بي (أيضًا كيف يعمل بوويرشيل):

أحب أن أستخدم cls ثم أدير npm test . ثم تكون بداية المحطة الطرفية حيث يبدأ إخراج الاختبار الخاص بي.
الآن أنا cls ، لكن ليس لدي أي فكرة عن مكان بداية مخرجات الاختبار الخاصة بي.

لذلك لا أوافق على مجرد إزاحة الصفوف.

إليك تقرير عن السلوك في مختلف برامج المحاكاة الطرفية عندما يتلقون إشارة Erase All ED ( \e[2J ):

• إكستريم. [email protected] : احتفظ بكل شيء ، فقط ادفعه لأعلى
• gnome-terminal: امسح كل شيء أعلى منفذ العرض الحالي ، ثم ادفع منفذ العرض الحالي لأعلى
• محطة فيدورا: نفس محطة جنوم
• xterm: مسح المخزن المؤقت بالكامل
• Terminal.app: مثل xterm. [email protected]
• iTerm2 v3: مثل xterm. [email protected]

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

بالنسبة لي ، يبدو سلوك xterm هو الأكثر منطقية ، لا سيما عند تنفيذ البحث (https://github.com/sourcelair/xterm.js/issues/553) ، لكن يمكنني معرفة سبب احتمال حدوث ذلك تكون جيدة لبعض المستخدمين. parisk ما رأيك؟ هل يجب أن يكون هذا إعدادًا (امسح كل شيء مقابل الدفع) أم يجب أن ننتقل إلى سلوك xterm؟

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

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

ما هي حالة الاستخدام التي يفضل شخص واحد إخفاء المخزن المؤقت بأكمله؟

يذكر CoenraadS واحدة كبيرة:

1. واضح
2. قم بتشغيل أمر بإخراج طويل
3. انتقل إلى بداية المخزن المؤقت لرؤية بداية الأمر

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

أعتقد أن هذا يجب أن يكون إعدادًا لأن قذائف Windows و Linux تتصرف بشكل مختلف ولا أرى ذلك مدرجًا في التقرير.

يقوم كل من Cmd و Powershell بمسح المخزن المؤقت عند استدعاء cls حتى لا تتمكن من التمرير لرؤية السجل.
CentOS باستخدام Bash ، الأمر الواضح يمسح الشاشة ولكنه يحافظ على المخزن المؤقت حتى تتمكن من التمرير لأعلى لرؤية السجل.

إليك ما أعتقد أنه ضروري لحل هذا بالكامل:

• قم بتعيين افتراضي استنادًا إلى نظام التشغيل للحفاظ على التوقعات بناءً على النظام الأساسي.
• السماح للمستخدم بالتجاوز لكل قذيفة. بهذه الطريقة ، يمكن لمستخدمي Windows Bash تغييره للحفاظ على المخزن المؤقت.
• السماح بإنشاء اختصارات أو أزرار لواجهة المستخدم بحيث يمكن للمستخدم القيام بأي منها بغض النظر عن الإعداد. قد يعمل شيء مثل ClearBuffer و ClearScreen.

يقودني هذا إلى فكرة رائعة للمكوِّن الإضافي: إذا قمت بالمسح ، فسيتم مسح المخزن المؤقت ، ولكن إذا قمت بالتمرير لأعلى بعد الطية الحالية ، فسترى سطرًا "تم مسح الإخراج السابق ، انقر هنا لعرضه" ، والذي يستعيد الإخراج. سيكون سلوكه مشابهًا لمحرر الكود حيث يمكنك توسيع / ​​طي الأقسام ، لكن أقسامنا مجمعة حسب أوامر واضحة. هل تعديل التمرير للخلف مثل هذا سيعمل بالفعل كمكوِّن إضافي حاليًا؟

mofux CircularList ربما يحتاج إلى أن يكون على دراية بالمناطق القابلة للطي لشيء من هذا القبيل.

+1 لمسح الشاشة فعليًا. أشارك حالة استخدام CoenraadS حيث أستخدمها لاختبارات الوحدة

إصدار كود VS | نظام التشغيل
------------------ | ----
1.10.2 | Win x64 Pro (فرنسي)

أؤكد أن تشغيل cls من المحطة المتكاملة لا يؤدي إلى مسح الجهاز. لا يزال بإمكانك التمرير لأعلى ومشاهدة الأوامر السابقة. هذا مع Powershell.exe أو cmd.exe.

سينتج عن أمر الكود هذا نفس النتيجة

{ "key": "ctrl+k", "command": "workbench.action.terminal.clear", "when": "terminalFocus" }

الحل البديل ، استخدم الأمر _clear terminal_ من اللوحة أو قم بتحرير رابط المفاتيح مع إزالة terminalFocus كـ

{ "key": "ctrl+k k", "command": "workbench.action.terminal.clear" }

لسوء الحظ ، لن تتمكن من تشغيل هذا المفتاح القصير بنجاح عندما يكون هناك تركيز على الجهاز.

هذا يحتاج إلى الإصلاح.

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

فهل هناك نية لإصلاح هذا في أي وقت قريب؟ هذا هو الشيء الأول الذي يمنعني من إسقاط ISE والانتقال إلى VSCode. لقد كنت أنتظر الإصلاح منذ حوالي عام الآن: - /

CookieCrumbles تم إصلاح هذا بالنسبة لي في إصدار VSCode Insider لأشهر

تضمين التغريدة

واجهت مشكلة في الإصدار 1.8 من Insiders ، وكانت هذه آخر مشكلة لدي. سأقوم بتنزيل الأحدث وأجرّب هذه المحاولة.
شكرا لرجوعك إلي. سأعيد النشر بأسرع ما يمكن.

تضمين التغريدة
يؤسفني أن أقول لكن إذا فعلت ذلك باستخدام بوويرشيل:

gci c:\temp cls gci c:\temp cls gci c:\temp cls gci c:\temp cls gci c:\temp

ما زلت قادرًا على التمرير لأعلى ومشاهدة GCI السابقة لـ c: temp.
لذلك لم يتم إصلاح هذا.

آه ، أنا على جهاز Mac. ربما لم يتم إصلاحه لنظام التشغيل Windows حتى الآن

أظن أن هذا ليس على رأس قائمة أولوياتهم. Kinda تخلت عن VSCode فقط بسبب هذا. بالعودة إلى ISE ، سأقوم بالتحقق مرة أخرى في غضون ستة أشهر أو نحو ذلك ، على أمل إصلاحه بحلول ذلك الوقت. # اشعر

نحن ندعم كل من مسح منفذ العرض (2J) ومخزن التمرير المؤقت (3J) ، ولست متأكدًا من وجود إصلاح لهذا الأمر لنظام التشغيل Linux / macOS بخلاف تضمين xterm.js في terminfo ، راجع https://unix.stackexchange.com/questions / 375743 / لماذا-مسح-عدم-مسح-كامل الشاشة

بالنسبة إلى Windows ، لست متأكدًا مما إذا كان هناك أي شيء يمكن القيام به من جانبنا أيضًا. rprichard ، هل لديك أية أفكار حول سبب إرسال برنامج winpty \e[2J وليس \e[3J أيضًا عند إجراء مسح في PowerShell؟

@ إصلاح

يلاحظ winpty بالتأكيد عند تشغيل الأمر CLS - تنتقل نافذة وحدة التحكم إلى الجزء العلوي من المخزن المؤقت لشاشة وحدة التحكم. عندما يحدث ذلك ، يقوم برنامج winpty بإعادة تعيين الجهاز. ربما يجب أن يرسل أمرًا مختلفًا عما يرسله حاليًا.

كان انطباعي أن مسح الشاشة لا يؤدي إلى إعادة تعيين التمرير إلى الوراء ، ولكن يبدو أنني كنت مخطئًا ، لذلك ربما يلزم تغيير ملف win32 هنا.

rprichard أعتقد أنه على Windows بشكل خاص cls يمسح التمرير باستمرار ، إنه يختلف على الأنظمة الأساسية الأخرى وأعتقد أن السبب في ذلك هو أن terminfo لا تعلن عن دعم 3J للبعض محطات.

حسنًا ، يسعدني أن أرى أنه يتم النظر إليه. آمل أن تتمكنوا يا رفاق من إصلاحه في المستقبل القريب.

أي تحديث Tyriar ؟

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

cls - القوة
cls -f

أي تحديثات؟ لا تزال مشكلة في VS Code ويبدو أنهم ينتظرون هذا بدلاً من إصلاحه في VS Code.

Cls بالتأكيد بمسح المخزن المؤقت والشاشة في رأيي ، كما هو الحال مع cmd.exe على النوافذ.

تحديث: أتوقع أن يتم إصلاح هذا عند معالجة https://github.com/Microsoft/vscode/issues/45693 ، والذي من المحتمل أن أعمل عليه في الأشهر المقبلة.

إغلاق هذا لأنه لا يتعلق بـ xterm.js ولكن بمحاكاة pty على Windows. يتم تتبع مشكلات Windows pty في https://github.com/Microsoft/vscode/issues/45693