Vimium: في وضع البحث ، قم بتمييز جميع التطابقات على الصفحة ، وليس فقط الحالية

تم إنشاؤها على ١٨ يوليو ٢٠١٢  ·  47تعليقات  ·  مصدر: philc/vimium

في وضع البحث عن الكروم ، يمكنه تمييز كل الكلمات المطابقة في الصفحة
هل يستطيع vimium أيضًا القيام بذلك؟

suggestions

التعليق الأكثر فائدة

بعد 6 سنوات ، ما زلت آمل في الحصول على هذه الميزة

ال 47 كومينتر

ليس الان. أعتقد أننا سنقبل التصحيح إذا لم يسبب تأخرًا ملحوظًا.

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

إذا انتهى بنا المطاف في هذه المشكلة ، فيجب علينا أن نقطع جمالية مباريات Safari ، IMO.

+1 لهذه الميزة.

+1

Vimium رائع! هذه هي القطعة الوحيدة المفقودة بالنسبة لي.

+1 لهذه الميزة. أردت في الواقع أن أقترح هذا بنفسي ، لكن كان لدي شعور "لا يمكنني أن أكون الوحيد".

Yeyahh!

+1

+1

إذا / عندما يتم تنفيذ هذا ، فسيكون من الجيد أيضًا رؤية جميع التطابقات المميزة بصريًا في شريط التمرير مثل Chromium.

+1

اكتشفت مؤخرًا حول vimium ، لا أصدق أنني لم أقم بتثبيت هذا عاجلاً.

+1

+1

+1

+1

+1
وأعتقد أن هذه ستكون ميزة قاتلة أخرى

+1

يرجى التوقف عن الرد بتعليقات +1 عديمة الفائدة. لا يضيف أي شيء إلى المناقشة ، وسيضيع الكثير من وقت الأشخاص لأنهم سيحصلون على إشعارات "بمساهمتك" غير المجدية. استخدم وظيفة "مشاهدة" للاشتراك في تذكرة.

+1

+1 ، يعمل الكروم الافتراضي في إبراز كل النتائج المتطابقة. إذا كان تطبيقه مرة أخرى يمثل مشكلة في الأداء ، فهل من الممكن الاتصال مباشرة ببحث chrome؟

هل من الممكن الاتصال مباشرة ببحث الكروم؟

لا.

لتنفيذ شيء من هذا القبيل ، قد يحتاج إلى شيء مثل (محدث) # 1081 حتى لا يتوقف المتصفح على كل بحث ، مما يزيد من عبء التطوير / الصيانة بشكل كبير.

إغلاق.
على الرغم من كونه شائعًا ، فليس لدينا طريقة لتنفيذ ذلك.

(لا يقوم Vimium بالتمييز على الإطلاق حاليًا. نحن فقط نسمي window.find() .)

4 سنوات ...

+1 هذه ميزة رائعة حقًا إذا كان من الممكن تنفيذها.

لقد قمت ببعض البحث. يبدو أن هذا يفعل ذلك http://stackoverflow.com/a/5887719/96100 (يتضمن الحل IE ، لذلك يمكن تبسيطه بشكل أكبر عن طريق إزالة جزء IE)

لكني أعتقد أن هناك سؤالًا آخر - متى وكيف يتم إزالة التمييز. عندما أفكر في ذلك عند بدء البحث التالي أو عند تنفيذ شيء مثل :noh ؛ بالنسبة للكيفية ، أفترض أن execCommand('undo') سيفعل ذلك.

نتطلع حقًا إلى الميزة.

هذا مطلوب ولست متأكدًا مما إذا كان من المفترض أن يكون ميزة خاصة بـ vimium ، لكن الامتدادات الأخرى الشبيهة بـ vim تفعل ذلك ( مثل مفاتيح التصفح على سبيل المثال ). لقد مرت بالفعل ما يقرب من 5 سنوات وهذه الميزة ليست هنا بعد. ماذا يحدث في العالم الذي يجري؟

لقد قمت ببعض البحث. يبدو أن هذا يفعل ذلك http://stackoverflow.com/a/5887719/96100 (يتضمن الحل IE ، لذلك يمكن تبسيطه بشكل أكبر عن طريق إزالة جزء IE)

يبدو أن هذا الحل يتضمن تعديلات مضمنة على DOMs للصفحات ، مما يجعلني غير مرتاح للغاية.

ماذا يحدث في العالم الذي يجري؟

من الصعب القيام بذلك بشكل صحيح (أو على الأقل يرضي).

التنفيذ الكامل يجب أن

  • البحث عبر العناصر (التي تبدو مفاتيح التصفح غير قادرة على القيام بها ؛ انظر هنا وهنا لمعرفة الكود الخاص بهم)

    • على سبيل المثال ابحث عن class SuppressPrintable وقم بتمييزه (أو حتى الأصعب ، قم بتمييز lass Supp ) في هذه الصفحة

    • لاحظ أن السطر الذي نهتم به يحتوي على HTML <span class="pl-k">class</span> <span class="pl-en" style="background-color: transparent;">SuppressPrintable</span> <span class="pl-k">extends</span> <span class="pl-e">Mode</span>

    • على سبيل المثال اعثر على testtest وقم بإبرازه في test<img src="#">test ، كما يفعل الاكتشاف الأصلي

    • ابحث عن testtest وقم بتمييزه في test<input type="text">test (مثل Firefox) أو لا (مثل Chrome).

  • البحث عن سلسلة منسوخة مباشرة من الصفحة وتمييزها. تنطبق حالتان:

    • الوالد لديه white-space: normal أو nowrap . test string كـ test string ، لذلك علينا إيجاد ذلك. (لا تستطيع surfingkeys القيام بذلك ، لأنها تستخدم node.data )

    • الوالد لديه white-space: pre ، pre-line أو pre-wrap . test string كـ test string ، لذلك علينا إيجاد ذلك

  • البحث عبر العناصر التي تمثل مسافة بيضاء (على سبيل المثال ، <br /> أو <p></p> ). (لا يمكن لمفاتيح التصفح القيام بذلك)

    • على سبيل المثال يجب العثور على Test<br />Test وإبرازه من خلال البحث عن Test\nTest ( أو ربما Test\r\nTest ؟ )

    • على سبيل المثال يجب العثور على <p>Test</p><p>Test</p> وتمييزه من خلال البحث عن Test\n\nTest (أو Test\r\n\r\nTest )

  • (اختياريًا) ابحث عن التطابقات وقم بتمييزها في <input> s ، <textarea> s ، <button> s ، إلخ. هذه مشكلة كبيرة للقيام بها بشكل صحيح.

يمكننا استخدام خاصية innerText للحصول على تمثيل نصي للصفحة ، والذي يخبرنا بمعظم التطابقات (باستثناء - على وجه الخصوص - تلك المذكورة في النقطة الأخيرة) ، وأي منها يستخدم Vimium. ومع ذلك ، لتمييز (أو حتى إنشاء تحديد دون استخدام window.find ) ، يتعين علينا تعيين نتائج البحث عن النص (على innerText ) مرة أخرى في نطاقات في DOM.

إن أسلوبي المقترح (الكسول) لذلك يتضمن نوعًا من البحث الثنائي للرجل الفقير ، وإنشاء Range s ، واستخدام toString() للتعيين إلى innerText . لست مهتمًا بشكل خاص بتنفيذ هذا بنفسي.

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

+1

بعد 6 سنوات ، ما زلت آمل في الحصول على هذه الميزة

  • راجع للشغل ، نفذ هذا المكون الإضافي Chrome Regex Search هذه الوظيفة.
  • سيكون من الرائع أن يدعم vimium هذا أيضًا.

يستخدم الامتداد Chrome Regex Search طريقة خطيرة جدًا لتنفيذ ميزة التمييز ، وقد يؤدي إلى تعطيل بعض صفحات الويب العادية لأنه قد يؤدي إلى تعطل كود JavaScript للمضيف وإزالة بعض إجراءات النقر.

لا يبدو لي هذا الموضوع وحدي.

لقد قمت ببعض البحث. يبدو أن هذا يفعل ذلك http://stackoverflow.com/a/5887719/96100 (يتضمن الحل IE ، لذلك يمكن تبسيطه بشكل أكبر عن طريق إزالة جزء IE)

يبدو أن هذا الحل يتضمن تعديلات مضمنة على DOMs للصفحات ، مما يجعلني غير مرتاح للغاية.

ماذا يحدث في العالم الذي يجري؟

من الصعب القيام بذلك بشكل صحيح (أو على الأقل يرضي).

التنفيذ الكامل يجب أن

  • البحث عبر العناصر (التي تبدو مفاتيح التصفح غير قادرة على القيام بها ؛ انظر هنا وهنا لمعرفة الكود الخاص بهم)

    • على سبيل المثال ابحث عن class SuppressPrintable وقم بتمييزه (أو حتى الأصعب ، قم بتمييز lass Supp ) في هذه الصفحة
    • لاحظ أن السطر الذي نهتم به يحتوي على HTML <span class="pl-k">class</span> <span class="pl-en" style="background-color: transparent;">SuppressPrintable</span> <span class="pl-k">extends</span> <span class="pl-e">Mode</span>
    • على سبيل المثال اعثر على testtest وقم بإبرازه في test<img src="#">test ، كما يفعل الاكتشاف الأصلي
    • ابحث عن testtest وقم بتمييزه في test<input type="text">test (مثل Firefox) أو لا (مثل Chrome).
  • البحث عن سلسلة منسوخة مباشرة من الصفحة وتمييزها. تنطبق حالتان:

    • الوالد لديه white-space: normal أو nowrap . test string كـ test string ، لذلك علينا إيجاد ذلك. (لا تستطيع surfingkeys القيام بذلك ، لأنها تستخدم node.data )
    • الوالد لديه white-space: pre ، pre-line أو pre-wrap . test string كـ test string ، لذلك علينا إيجاد ذلك
  • البحث عبر العناصر التي تمثل مسافة بيضاء (على سبيل المثال ، <br /> أو <p></p> ). (لا يمكن لمفاتيح التصفح القيام بذلك)

    • على سبيل المثال يجب العثور على Test<br />Test وإبرازه من خلال البحث عن Test\nTest ( أو ربما Test\r\nTest ؟ )
    • على سبيل المثال يجب العثور على <p>Test</p><p>Test</p> وتمييزه من خلال البحث عن Test\n\nTest (أو Test\r\n\r\nTest )
  • (اختياريًا) ابحث عن التطابقات وقم بتمييزها في <input> s ، <textarea> s ، <button> s ، إلخ. هذه مشكلة كبيرة للقيام بها بشكل صحيح.

يمكننا استخدام خاصية innerText للحصول على تمثيل نصي للصفحة ، والذي يخبرنا بمعظم التطابقات (باستثناء - على وجه الخصوص - تلك المذكورة في النقطة الأخيرة) ، وأي منها يستخدم Vimium. ومع ذلك ، لتمييز (أو حتى إنشاء تحديد دون استخدام window.find ) ، يتعين علينا تعيين نتائج البحث عن النص (على innerText ) مرة أخرى في نطاقات في DOM.

إن أسلوبي المقترح (الكسول) لذلك يتضمن نوعًا من البحث الثنائي للرجل الفقير ، وإنشاء Range s ، واستخدام toString() للتعيين إلى innerText . لست مهتمًا بشكل خاص بتنفيذ هذا بنفسي.

أقوم أيضًا ببعض الأبحاث على window.find (). إنه يبرز النتيجة الحالية فقط على الويب ، ولا يبرز كل النتيجة. ربما استدعاء الطريقة عدة مرات؟ أعتقد أنها ليست فكرة جيدة لهذه المسألة.

ماذا عن هذا الروتين؟

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

بعد الاستخدام ، اضغط على مفتاح الإدخال ، واستدعاء window.find () لإظهار جميع التكرارات.
[ربما ، لتذكر موضع نتيجة البحث قبل الدخول مباشرةً]

window.find() دائمًا المنطقة المحددة "الحالية" ، بينما لا توجد طريقة مثالية لمحاكاة كتلة لون الخلفية (على سبيل المثال ، إذا كان الخط يمتلك لون / صورة الخلفية ، فسيكون لون الخلفية المحاكى غير مرئي).

window.find() دائمًا المنطقة المحددة "الحالية" ، بينما لا توجد طريقة مثالية لمحاكاة كتلة لون الخلفية (على سبيل المثال ، إذا كان الخط يمتلك لون / صورة الخلفية ، فسيكون لون الخلفية المحاكى غير مرئي).

مرحباً ، دعني أكون أكثر وضوحاً بشأن روتيني.

نوع المستخدم a ، اتصل بـ window.find حتى يتم إرجاعه NULL. اجمع كل المباريات
نوع المستخدم ab ، اتصل بـ window.find حتى يتم إرجاعه NULL. جمع كل المباريات ، وإسقاط السابق
عند استخدام ضرب enter ، استخدم بالفعل مصفوفة نتائج البحث.

تسقطPiping window.find() دائمًا جميع مناطق التظليل القديمة ثم تبرز واحدة جديدة فقط ، لذلك في الواقع لا توجد واجهات برمجة تطبيقات JavaScript لإبراز قائمة المناطق.

إخلاء المسؤولية: لم أعد أعمل على ملحقات المتصفح بأي شكل من الأشكال ، لذلك من المحتمل أن تكون معرفتي قديمة.

نوع المستخدم a ، اتصل بـ window.find حتى يتم إرجاعه NULL . اجمع كل المباريات
نوع المستخدم ab ، اتصل بـ window.find حتى يتم إرجاعه NULL . جمع كل المباريات ، وإسقاط السابق

window.find أمر مروع ويجب تجنبه كلما أمكن ذلك

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

    • كما يذكر Dahan بحق ، يتم دائمًا تجاهل التمييز الحقيقي ، لذلك يتعين علينا جمع هذا لتسليط الضوء على أكثر من مباراة واحدة

    • من الصعب استخراج هذه البيانات من <input> / <textarea> s ، حتى قبل أن نضطر إلى القلق بشأن المشكلة غير التافهة المتمثلة في تمييز النص فيها.

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

@ gdh1995 لم أقصد استخدام windows.find() بهذه الطريقة كما قلت. إنه مجرد نص find .
@ mrmr1993 أنا أفهم أن هذه الميزة تتطلب مزيدًا من قوة الحوسبة أو الجهد / لا يعمل كما هو متوقع (ولا حتى في vim).

هل هناك أي شيء آخر غير السبب الفلسفي الذي يجعل الامتداد لا يسمح فقط بهذا النوع من الميزات ، ويضعه في قسم "تجريبي" من إعدادات الامتداد ، مع وجود تحذيرات مناسبة تشير إلى أنه قد يؤدي إلى كسر بعض الصفحات؟ يبدو هذا كافيًا لطلب شائع بحيث يكون من المنطقي إضافته هناك. لقد كنت سعيدًا جدًا بالامتداد " Selection Highlighter " على سبيل المثال ، على الرغم من حقيقة أنه قد يؤدي إلى كسر الصفحات ، وذلك ببساطة لأن الأداة المساعدة تفوق المخاطر ؛ أعتقد أن الأمر نفسه ينطبق هنا.

+1 هنا. :)

أنا أردد مشاعر ماكنتاكو.

أستخدم البحث vimium كبديل لأداة البحث حتى أتمكن من الحفاظ على اختصارات لوحة المفاتيح موحدة عبر عمليات التثبيت المختلفة (استخدم دائمًا / للعثور على الأشياء).

+1

يحتوي Firefox على browser.find.find و browser.find.highlightResults . لا يبدو أنه يدعم regex ، ولكن بخلاف ذلك يبدو بالضبط ما ستحتاجه هذه المشكلة.

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

+1 - أتمنى لو كان هناك حل بديل لهذا على الأقل.

8 سنوات... :)

حصلت مؤخرًا على فكرة أخرى: ليس من الضروري رسم لون الخلفية المميز ، وقد نستخدم أقنعة مستطيلة بدلاً من ذلك. لذلك قمت بتطبيق إصدار بسيط في Vimium المخصص لي ، Vimium C ، وهو يدعم Ctrl+J/K للعثور على التالي / السابق و Ctrl+Shift+J/K لميض المستطيل على جميع التطابقات في المنطقة المرئية الحالية.

هل كانت هذه الصفحة مفيدة؟
0 / 5 - 0 التقييمات