Vimium: 検索モードで、現在の一致だけでなく、ページ上のすべての一致を強調表示します

現時点ではない。 目立ったラグが発生しなければ、パッチを受け入れると思います。

これはかなり大規模な作業になります。引き続きwindow.find（）を使用して検索を実行すると仮定すると、すべての一致を表示してから独自のハイライトUIを表示するために、これを繰り返し呼び出す必要があります。

私たちがその問題を経験することになった場合、Safariのマッチの美学であるIMOを取り除く必要があります。

この機能の+1。

+1

Vimiumは素晴らしいです！ 私の知る限り、これが唯一欠けている部分です。

この機能の+1。 実は自分で提案したかったのですが、「自分だけじゃない」という気持ちがありました。

うん！

+1

+1

これが実装された場合、Chromiumのように、スクロールバーにすべての一致が視覚的にマークされているのを確認するのもよいでしょう。

+1

最近vimiumについて知りましたが、これを早くインストールしなかったなんて信じられません。

+1

+1

+1

+1

+1
これはもう1つのキラー機能になると思います

+1

無駄な+1コメントで返信するのはやめてください。 それは議論に何も追加せず、彼らがあなたの役に立たない「貢献」の通知を受け取るので、多くの人々の時間を無駄にします。 「ウォッチ」機能を使用して、チケットをサブスクライブします。

+1

+1の場合、デフォルトのクロムは一致したすべてのヒットを強調表示するように動作します。 それを再度実装することがパフォーマンスの問題になる場合、chromeの検索を直接呼び出すことは可能ですか？

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の部分を削除することでさらに簡略化できます）

このソリューションには、ページのDOMのインライン変更が含まれているようで、非常に不快です。

世界で何が起こっているのですか？

これを適切に行うのは困難です（または、少なくとも私の満足のいくように）。

完全な実装はする必要があります

• 要素全体を検索します（surfingkeysでは実行できないように見えます。コードについてはこことここを参照してください）
  
  
  
  • 例えば。 このページで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>があることに注意してください
  
  
  • 例えば。 ネイティブ検索と同様に、 test<img src="#">testでtesttestを検索して強調表示します
  
  
  • test<input type="text">test testtestを見つけて強調表示するか（Firefoxのように）、表示しない（Chromeのように）。
  
  
• ページから直接コピーされた文字列を見つけて強調表示します。 2つのケースが適用されます。
  
  
  
  • 親はwhite-space: normalまたはnowrap持っています。 test stringはtest stringとしてレンダリングされるので、それを見つける必要があります。 （ node.data使用するため、surfingkeysはこれを行うことができません）
  
  
  • 親にはwhite-space: pre 、 pre-lineまたはpre-wrapます。 test stringはtest stringとしてレンダリングされるので、それを見つける必要があります
  
  
• 空白を表す要素全体を検索します（例： <br />または<p></p> ）。 （surfingkeysはこれを行うことができません）
  
  
  
  • 例えば。 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 RegexSearchはこの機能を実装しました。
• vimiumもこれをサポートできれば素晴らしいと思います。

拡張機能Chrome Regex Searchは、非常に危険な方法を使用して強調表示機能を実装し、ホストJavaScriptコードを破壊して一部のクリックアクションを削除する可能性があるため、通常のWebページを破壊する可能性があります。

私だけがこの問題を抱えているわけではないようです。

私はいくつかの調査をしました。 これはそれを行うようですhttp://stackoverflow.com/a/5887719/96100 （ソリューションにはIEが含まれているため、IEの部分を削除することでさらに簡略化できます）

このソリューションには、ページのDOMのインライン変更が含まれているようで、非常に不快です。

世界で何が起こっているのですか？

これを適切に行うのは困難です（または、少なくとも私の満足のいくように）。

完全な実装はする必要があります

• 要素全体を検索します（surfingkeysでは実行できないように見えます。コードについてはこことここを参照してください）

  • 例えば。 このページで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>があることに注意してください
  • 例えば。 ネイティブ検索と同様に、 test<img src="#">testでtesttestを検索して強調表示します
  • test<input type="text">test testtestを見つけて強調表示するか（Firefoxのように）、表示しない（Chromeのように）。

• ページから直接コピーされた文字列を見つけて強調表示します。 2つのケースが適用されます。

  • 親はwhite-space: normalまたはnowrap持っています。 test stringはtest stringとしてレンダリングされるので、それを見つける必要があります。 （ node.data使用するため、surfingkeysはこれを行うことができません）
  • 親にはwhite-space: pre 、 pre-lineまたはpre-wrapます。 test stringはtest stringとしてレンダリングされるので、それを見つける必要があります

• 空白を表す要素全体を検索します（例： <br />または<p></p> ）。 （surfingkeysはこれを行うことができません）

  • 例えば。 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（）についても調査を行っています。 Web上の現在の結果のみを強調表示し、すべての結果を強調表示するわけではありません。 たぶん、メソッドを複数回呼び出しますか？ この問題については良い考えではないと思います。

このルーチンはどうですか？

検索モードでは、ユーザーがEnterキーを押す前に、更新された入力ごとにwindow.find（）を1回だけ呼び出します。

使用後、Enterキーを押し、window.find（）を呼び出して、すべての出現箇所を表示します。
[おそらく、入力する直前の検索結果の位置を覚えておくために]

window.find()常に「現在の」選択された領域を強調表示しますが、背景色ブロックをシミュレートする完全な方法はありません（たとえば、線がその背景色/画像を所有している場合、シミュレートされた背景色は非表示になります）。

window.find()常に「現在の」選択された領域を強調表示しますが、背景色ブロックをシミュレートする完全な方法はありません（たとえば、線がその背景色/画像を所有している場合、シミュレートされた背景色は非表示になります）。

こんにちは、私のルーチンについてもっと明確にしましょう。

ユーザータイプa 、NULLが返されるまでwindow.find呼び出します。 すべての試合を収集する
ユーザータイプab 、NULLが返されるまでwindow.find呼び出します。 すべての一致を収集し、前にドロップします
ヒットenter使用する場合は、実際に検索結果の配列を利用してください。

@Piping window.find()常にすべての古い強調表示領域を強調表示領域のみを強調表示するため、実際には領域のリストを強調表示するJavaScriptAPIはありません。

免責事項：私はもはやブラウザ拡張機能に取り組んでいないため、私の知識は古くなっている可能性があります。

ユーザータイプa 、 NULLが返されるまでwindow.find呼び出します。 すべての試合を収集する
ユーザータイプab 、 NULLが返されるまでwindow.find呼び出します。 すべての一致を収集し、前にドロップします

window.findはひどいので、可能な限り避ける必要があります

• メインスレッドで実行されるため、ユーザー入力をブロックします
• UI効果があるため、レンダリングを強制し、さらにユーザー入力をブロックします
• これは選択ベースであるため、テキストの選択をブロックするCSSは、選択したブラウザーに応じて、さまざまな奇妙な動作をする可能性があります。
• FFでラップしません（または少なくとも、以前は使用していませんでした）
• これは仕様の範囲外であり、公式に非推奨であり、ブラウザ間の動作を標準化する意図はありません。
• この方法で選択データを取得することは、DOMに直接クエリを実行するよりもはるかにコストがかかります。
  
  
  
  • Dahanが正しく言及しているように、真のハイライトは常に破棄されるため、複数の一致をハイライトするにはこれを収集する必要があります
  
  
  • <input> / <textarea>は、テキストを強調表示するという重要な問題を心配する前であっても、このデータをうまく取得するのは困難です。
  
  

私が寄稿者だったとき、大きなページでは検索結果の数が非常に遅いため、検索結果の数を数えることをめぐって争いました。 window.findは、約1桁遅く、正規表現検索ではまったく機能しませんでした。 単一の検索を実行する以上の目的で使用することは強くお勧めします。それでも、最後の手段となるはずです。

@ gdh1995あなたが言ったように、私はwindows.find()そのように使うつもりはありません。 単なるfindのテキストです。
@ mrmr1993この機能には、より多くの計算能力または人的労力が必要であることを理解しています。 ただし、少なくともユーザーは、ユーザーの観点から見て遅い場合でも、vimiumを使用してこれを行うための[構成のオプション]を選択する必要があります。 とにかく、Ctrl-Fが使われることもあれば、/が使われることもあり、 /が期待どおりに機能しない（vimでも）のはちょっと面倒です。

拡張機能がこのタイプの機能を許可できず、拡張機能の設定の「実験的」セクションに押し込み、一部のページが破損する可能性があることを示す適切な警告を表示するという哲学的な理由以外に何かありますか？ これは人気のあるリクエストで十分なようで、そこに追加するのは理にかなっています。 たとえば、ユーティリティがリスクを上回っているという理由だけでページが壊れる可能性があるという事実にもかかわらず、拡張機能「 SelectionHighlighter 」には非常に満足しています。 ここでも同じことが言えると思います。

このあたりで+1。 :)

私はmacintacoの感情を反映しています。

検索ツールの代わりにvimium検索を使用して、インストールごとにキーボードショートカットを統一できるようにしています（常に/を使用して検索します）。

+1

Firefoxにはbrowser.find.findとbrowser.find.highlightResultsます。 正規表現をサポートしているようには見えませんが、それ以外の点では、この問題に必要なものとまったく同じように見えます。

SurfingKeysは、検索機能を介してページ上の一致を強調表示します。 彼らがそれをどのように行うのかはわかりませんが（ある種のオーバーレイのようです）、代わりにその拡張機能を使用しているという点では「十分」です。 YMMV。

+ 1-少なくともこれに対する回避策があったらいいのにと思います。

8年... ：）

最近、別のアイデアが浮かびました。ハイライトの背景色を描画する必要はなく、代わりにマスキング四角形を使用する場合があります。 したがって、カスタマイズしたVimiumであるVimium Cに単純なバージョンを実装しました。これは、 Ctrl+J/Kをサポートして次/前を検索し、 Ctrl+Shift+J/Kをサポートして現在の表示領域のすべての一致で四角形をフラッシュします。