Xterm.js: التحديد مع البحث و unicode

يبدو أنه يعمل بشكل جيد بالنسبة لي على mac / master ، اسمح لي أن أعرف إذا كنت لا تزال تراه.

Tyriar كلا لم يذهب ، لا يزال هو نفسه هنا. ربما انها قضية منصة؟

يبدو مثل هذا الصراف الآلي:

يبدو أن حرف التمييز يتم احتسابه لمحرفي عرض نصف عرض بواسطة المحدد ، بينما يتم التعامل مع الرمز ￥ على أنه نصف عرض واحد.

وجدت هذا في الكود:
https://github.com/xtermjs/xterm.js/blob/9e446a9a0e9f62899c450b28d78877b81a19724d/src/addons/search/SearchHelper.ts#L210

يجب أن تكون الوسيطة الأخيرة Imho هي مجموع wcwidth بدلاً من طول السلسلة (لم يتم اختبارها بعد).

jerch هل أنت على لينكس؟

نعم Ubuntu 16 هنا.

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

نفس المشكلة الأساسية لـ https://github.com/xtermjs/xterm.js/issues/1059؟

لا ، هذه المرة ليس خطأ wcwidth ، تغيير الحجة التي ذكرتها أعلاه يعمل على إصلاح المشكلات (تم اختباره قبل بضع دقائق)

محظور حاليًا بواسطة # 1707 و # 1709.

بعض المعلومات الأساسية عن هذا:
لا تزال الطريقة التي يتم بها تحديد نقطة البداية والنهاية للاختيار لا تعمل مع جميع البدائل ومجموعات أحرف عرض كامل - وبالتالي إذا كان هناك أي من تلك الموجودة في السطر قبل المباراة أو في المباراة نفسها ، يمكن أن تحدث تعويشات البداية والنهاية.

يمكن إصلاح ذلك بنفس الطريقة التي اضطررت إلى إصلاح الرابط الذي تحته خط في # 1769 ، عن طريق تعيين فهرس سلسلة إلى فهرس المخزن المؤقت:
https://github.com/xtermjs/xterm.js/blob/c7fa89da8e97e907cdfb72b23eabf5c3a5d1bb9e/src/Linkifier.ts#L223

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

لا يزال هذا يحدث. هذا هو خط المشكلة:

https://github.com/xtermjs/xterm.js/blob/cad9477eef22c0e505337c1f634f9f35a8804edc/addons/xterm-addon-search/src/SearchAddon.ts#L345

result.term.length لـ ééé هو 6 ، من المحتمل أن يتضمن الإصلاح العودة من _fineInLine صف نهاية وعمود بدلاً من المصطلح الفعلي.

مرحبًا ، أود الانضمام إلى زميلي @ miggs125 في المساهمة في xterm من خلال معالجة هذه المشكلة.

سأحاول أولاً تحسين اختيار السلاسل التي تتضمن علامات التشكيل.

Silvyre شيء أكيد. لاحظ أن المخزن المؤقت الطرفي يقوم بالفعل بتسجيل الأحرف المميزة في خلية واحدة بالحرف الرئيسي ، وبالتالي تأتي المشكلة من موضع السلسلة إلى التعيين الخلفي للخلية.

jerch شكرا!

لاحظ أن المخزن المؤقت الطرفي يقوم بالفعل بتسجيل أحرف التشكيل في خلية واحدة بالحرف الرئيسي

هل تشير إلى نوع JoinCellData ؟ بقدر ما أستطيع أن أقول ، لا يتم استخدام هذا النوع الأساسي حاليًا ضمن تحديد البحث (يبدو أن اختيار البحث يتعامل مع الخلايا العازلة ككائنات من نوع IBufferCell ، وهو ليس جزءًا من التسلسل الهرمي لـ ICellData ).

تغيير الحجة التي ذكرتها أعلاه يعمل على إصلاح المشكلات (تم اختباره قبل بضع دقائق)

البدء في الحصول على نفس الصفحة. حسنًا ، يبدو أن تعديل getStringCellWidth(term) بدلاً من term يحسن اختيار الأحرف المميزة ، على سبيل المثال ééé (على الأقل على Ubuntu 18.04 ؛ getStringCellWidth () يستدعى wcwidth () ، والتي قد تؤدي بشكل مختلف على الأنظمة الأساسية الأخرى؟).

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

لا يزال اختيار ￥ غير رائع ، على الأقل في Ubuntu 18.04

للتوضيح ، فإنه يعمل أحيانًا ، كما هو موضح في ملف GIF هذا ، الذي قمت بإنشائه بعد استبدال كل مثيل line/term/cell.length بـ getStringCellWidth(...) في SearchAddon.ts . سأحاول تعديل وظائف البحث أكثر قليلاً ومعرفة ما إذا كان بإمكاني تحسين السلوك بهذه الطريقة.

Silvyre نعم العمل مع تصحيح wcwidth هو الطريق الصحيح للذهاب هنا. احتاج Imho مرة واحدة لمصطلح البحث نفسه (في حالة احتوائه على أحرف غريبة) للحصول على كمية الخلايا المأخوذة ("طول الخلية") ، فأنت بحاجة إلى تصحيح كل إزاحة بداية تم العثور عليها بالمثل للعثور على إزاحة الخلية الحقيقية. يجب أن تعطي إزاحة الخلية + طول الخلية - طول٪٪ موضع البداية والنهاية الحقيقيين في المخزن المؤقت.

jerch ممتاز ، سأعمل على ذلك. شكرا لك مرة أخرى!

لدي سؤال عام بخصوص الوظائف الإضافية والتبعيات: كيف يتم استيراد الدوال المساعدة في src/common (على سبيل المثال getStringCellWidth ، wcwidth من CharWidth.ts ) إلى addons/xterm-addon-search )؟

Silvyre لم يتم توسيع واجهة API العامة عند الطلب. وبالتالي عليك الذهاب مع الحكام الداخليين في الوقت الحالي. ربما نفتح مشكلة بخصوص هذا حتى نتمكن من تحديد كيفية ومكان طرحه.

بالتأكيد ، سأفتح مشكلة.

ستحتاج إلى تصحيح كل إزاحة بداية تم العثور عليها بالمثل للعثور على إزاحة الخلية الحقيقية

jerch أواجه صعوبة في تحديد كيف وأين يجب تنفيذ (أو) تعويض الخلية. داخل BufferLine.ts ؟

لقد لاحظت أيضًا أن selectionEnd يبدو أنه يقضي معظم وقته غير محدد ، بينما يتم تعريف finalSelectionEnd . خطأ مرتبط ، ربما؟

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

jerch أواجه صعوبة في تحديد كيف وأين يجب تنفيذ (أو) تعويض الخلية. داخل BufferLine.ts؟

آه نعم ، هذا قليل مخفي في قاعدة الكود ، الكود المتعلق بهذا موجود في Buffer.ts و BufferLine.ts ، كلاهما يحتوي على عدة طرق توضح كيفية السير في الخلايا ، أسهل نقطة بداية قد تكون: https://github.com/xtermjs/ xterm.js / blob / e8153d929d6bb4f7012d3f20aa8c74abc335715d / src / common / buffer / Buffer.ts # L480

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

أنا أستخدم VSCode (1.50.0) على macOS Catalina (10.15.6) ولا تزال هذه المشكلة تحدث.

Tyriar مرحبًا ، إذن هل للمشكلة أي حلول؟ حاولت تحميل xterm-addon-unicode11 ، يمكنه فقط إصلاح عرض رموز الرموز التعبيرية ولكن البحث عن الأحرف الصينية لا يزال يواجه المشكلة.

لقد مرت فترة من الوقت منذ أن نظرت إلى هذا الرمز ولكن أعتقد أنه يمكننا الكشف عن IUnicodeVersionProvider 's wcwidth النشط إلى الامتدادات عبر IUnicodeHandling.activeProvider.wcwidth أو ما شابه ذلك لحل هذا الأمر.