Vimium: En mode recherche, mettez en surbrillance toutes les correspondances sur la page, pas seulement la

Pas pour le moment. Je pense que nous accepterions un correctif s'il ne provoquait pas de décalage notable.

Ce serait une entreprise assez importante - en supposant que nous utilisions toujours window.find () pour effectuer la recherche, nous aurions besoin de l'appeler à plusieurs reprises pour faire apparaître toutes les correspondances, puis afficher notre propre interface utilisateur de surbrillance.

Si nous finissons par traverser ce problème, nous devrions arnaquer l'esthétique des matchs de Safari, IMO.

+1 pour cette fonctionnalité.

+1

Vimium est génial ! C'est la seule pièce manquante en ce qui me concerne.

+1 pour cette fonctionnalité. En fait, je voulais suggérer cela moi-même, mais j'avais ce sentiment "je ne peux pas être le seul".

Ouais !

+1

+1

Si/quand cela sera implémenté, il serait également agréable de voir toutes les correspondances marquées visuellement dans la barre de défilement comme le fait Chromium.

+1

J'ai récemment découvert vimium, je ne peux pas croire que je ne l'ai pas installé plus tôt.

+1

+1

+1

+1

+1
et je pense que ce serait une autre fonctionnalité qui tue

+1

s'il vous plaît ARRÊTEZ de répondre avec des commentaires +1 inutiles. cela n'ajoute rien à la discussion et fera perdre beaucoup de temps aux gens puisqu'ils recevront des notifications de votre "contribution" inutile. utilisez la fonction « watch » pour souscrire à un ticket.

+1

+1, le chrome par défaut se comporte en mettant en évidence tous les hits correspondants. Si l'implémenter à nouveau était un problème de performances, est-il possible d'appeler directement la recherche de chrome ?

est-il possible d'appeler directement la recherche de chrome ?

Non.

Pour implémenter quelque chose comme cela, il faudrait quelque chose comme (une mise à jour) #1081 afin que le navigateur ne se bloque pas à chaque recherche, ce qui augmente considérablement la charge de développement/maintenance.

Fermeture.
Aussi populaire qu'il soit, nous n'avons pas vraiment de moyen de le mettre en œuvre.

(Vimium ne fait pas du tout la mise en évidence actuellement. Nous appelons simplement window.find() .)

4 années...

+1 C'est vraiment une excellente fonctionnalité si elle peut être implémentée.

J'ai fait des recherches. Cela semble le faire http://stackoverflow.com/a/5887719/96100 (la solution inclut IE, elle peut donc être encore simplifiée en supprimant la partie IE)

Mais je pense qu'il y a une autre question - quand et comment supprimer le surlignage. Pour quand, je pense au démarrage de la prochaine recherche ou lors de l'exécution de quelque chose comme :noh ; pour savoir comment, je suppose que execCommand('undo') ferait.

J'ai vraiment hâte de voir la fonctionnalité.

Ceci est nécessaire et je ne sais pas si c'est censé être une fonctionnalité spécifique à vimium, mais d'autres extensions de type vim le font ( comme surfingkeys par exemple ). Cela fait déjà près de 5 ans et cette fonctionnalité n'est pas encore là. Que se passe-t-il dans le monde ?

J'ai fait des recherches. Cela semble le faire http://stackoverflow.com/a/5887719/96100 (la solution inclut IE, elle peut donc être encore simplifiée en supprimant la partie IE)

Cette solution semble impliquer des modifications en ligne des DOM des pages, ce qui me met très mal à l'aise.

Que se passe-t-il dans le monde ?

C'est difficile à faire correctement (ou, du moins, à ma satisfaction).

Une mise en œuvre complète devrait

• trouver à travers les éléments (ce que surfingkeys semble incapable de faire ; voir ici et ici pour leur code)
  
  
  
  • par exemple. trouvez et mettez en surbrillance class SuppressPrintable (ou, encore plus difficile, mettez en surbrillance lass Supp ) sur cette page
  
  
  • notez que la ligne qui nous intéresse contient du 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>
  
  
  • par exemple. trouver et mettre en surbrillance testtest dans test<img src="#">test , comme le fait la recherche native
  
  
  • recherchez et mettez en surbrillance testtest dans test<input type="text">test (comme Firefox) ou ne le faites pas (comme Chrome).
  
  
• rechercher et mettre en surbrillance une chaîne copiée directement à partir d'une page. Deux cas s'appliquent :
  
  
  
  • le parent a white-space: normal ou nowrap . test string rendu comme test string , nous devons donc le trouver. (surfingkeys ne peut pas le faire, car il utilise node.data )
  
  
  • le parent a white-space: pre , pre-line ou pre-wrap . test string rendu comme test string , nous devons donc trouver cela
  
  
• rechercher parmi les éléments qui représentent des espaces (par exemple, <br /> ou <p></p> ). (les touches de surf ne peuvent pas faire ça)
  
  
  
  • par exemple. Test<br />Test doit être trouvé et mis en évidence en recherchant Test\nTest ( ou peut-être Test\r\nTest ? )
  
  
  • par exemple. <p>Test</p><p>Test</p> doit être trouvé et mis en évidence en recherchant Test\n\nTest (ou Test\r\n\r\nTest )
  
  
• (éventuellement) recherchez et mettez en surbrillance les correspondances dans <input> s, <textarea> s, <button> s, etc. C'est un gros problème à faire correctement.

Nous pouvons utiliser la propriété innerText pour obtenir une représentation textuelle de la page, qui nous indique la plupart des correspondances (sauf -- notamment -- celles mentionnées au dernier point), et que Vimium utilise. Cependant, pour mettre en évidence (ou même créer une sélection sans utiliser window.find ), nous devons mapper les résultats de la recherche de texte (sur innerText ) dans des plages du DOM.

Mon approche (paresseuse) suggérée pour cela impliquerait une sorte de recherche binaire du pauvre, créant Range s , et utilisant toString() pour mapper dans innerText . Je ne suis pas particulièrement intéressé à mettre cela en œuvre moi-même.

On dirait que c'est une fonctionnalité hautement souhaitée, mais peut-être que toutes les exigences prises ensemble sont trop importantes pour être traitées. Peut-être qu'un plus petit ensemble de sous-étapes pourrait rendre cela plus accessible.

+1

6 ans plus tard, j'espère toujours avoir cette fonctionnalité

• btw, ce plugin Chrome Regex Search a implémenté cette fonction.
• Ce serait formidable si vimium pouvait également prendre en charge cela.

L'extension Chrome Regex Search utilise un moyen très dangereux d'implémenter la fonction de surbrillance et peut casser certaines pages Web normales car elle peut casser le code JavaScript de l'hôte et supprimer certaines actions de clic.

Il semble que non seulement moi ai ce problème.

J'ai fait des recherches. Cela semble le faire http://stackoverflow.com/a/5887719/96100 (la solution inclut IE, elle peut donc être encore simplifiée en supprimant la partie IE)

Cette solution semble impliquer des modifications en ligne des DOM des pages, ce qui me met très mal à l'aise.

Que se passe-t-il dans le monde ?

C'est difficile à faire correctement (ou, du moins, à ma satisfaction).

Une mise en œuvre complète devrait

• trouver à travers les éléments (ce que surfingkeys semble incapable de faire ; voir ici et ici pour leur code)

  • par exemple. trouvez et mettez en surbrillance class SuppressPrintable (ou, encore plus difficile, mettez en surbrillance lass Supp ) sur cette page
  • notez que la ligne qui nous intéresse contient du 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>
  • par exemple. trouver et mettre en surbrillance testtest dans test<img src="#">test , comme le fait la recherche native
  • recherchez et mettez en surbrillance testtest dans test<input type="text">test (comme Firefox) ou ne le faites pas (comme Chrome).

• rechercher et mettre en surbrillance une chaîne copiée directement à partir d'une page. Deux cas s'appliquent :

  • le parent a white-space: normal ou nowrap . test string rendu comme test string , nous devons donc le trouver. (surfingkeys ne peut pas le faire, car il utilise node.data )
  • le parent a white-space: pre , pre-line ou pre-wrap . test string rendu comme test string , nous devons donc trouver cela

• rechercher parmi les éléments qui représentent des espaces (par exemple, <br /> ou <p></p> ). (les touches de surf ne peuvent pas faire ça)

  • par exemple. Test<br />Test doit être trouvé et mis en évidence en recherchant Test\nTest ( ou peut-être Test\r\nTest ? )
  • par exemple. <p>Test</p><p>Test</p> doit être trouvé et mis en évidence en recherchant Test\n\nTest (ou Test\r\n\r\nTest )
• (éventuellement) recherchez et mettez en surbrillance les correspondances dans <input> s, <textarea> s, <button> s, etc. C'est un gros problème à faire correctement.

Nous pouvons utiliser la propriété innerText pour obtenir une représentation textuelle de la page, qui nous indique la plupart des correspondances (sauf -- notamment -- celles mentionnées au dernier point), et que Vimium utilise. Cependant, pour mettre en évidence (ou même créer une sélection sans utiliser window.find ), nous devons mapper les résultats de la recherche de texte (sur innerText ) dans des plages du DOM.

Mon approche (paresseuse) suggérée pour cela impliquerait une sorte de recherche binaire du pauvre, créant Range s , et utilisant toString() pour mapper dans innerText . Je ne suis pas particulièrement intéressé à mettre cela en œuvre moi-même.

Je fais aussi des recherches sur window.find(). Il ne met en évidence que le résultat actuel sur le Web, et non tout le résultat. Peut-être appeler la méthode plusieurs fois ? Je pense que ce n'est pas une bonne idée pour ce problème.

que diriez-vous de cette routine?

en mode recherche, avant que les utilisateurs n'appuient sur la touche Entrée, n'appelez window.find() qu'une seule fois pour chaque entrée mise à jour.

après utilisation, appuyez sur la touche Entrée, appelez window.find() pour afficher toutes les occurrences.
[ éventuellement, pour se souvenir de la position du résultat de la recherche juste avant d'entrer ]

window.find() met toujours en surbrillance la zone sélectionnée "actuelle", alors qu'il n'y a pas de méthode parfaite pour simuler le bloc de couleur d'arrière-plan (par exemple, si une ligne possède sa couleur/image d'arrière-plan, la couleur d'arrière-plan simulée sera invisible).

window.find() met toujours en surbrillance la zone sélectionnée "actuelle", alors qu'il n'y a pas de méthode parfaite pour simuler le bloc de couleur d'arrière-plan (par exemple, si une ligne possède sa couleur/image d'arrière-plan, la couleur d'arrière-plan simulée sera invisible).

Bonjour, Je vais être plus clair sur ma routine.

L'utilisateur tape a , appelle window.find jusqu'à ce qu'il renvoie NULL. collecter tous les matchs
L'utilisateur tape ab , appelle window.find jusqu'à ce qu'il renvoie NULL. collecter toutes les correspondances, supprimer le précédent
Lorsque vous utilisez enter , utilisez réellement le tableau des résultats de la recherche.

@Piping window.find() supprime toujours toutes les anciennes zones de surbrillance, puis n'en met en évidence qu'une nouvelle, donc en fait, il n'y a pas d'API JavaScript pour mettre en évidence une liste de zones.

Avis de non-responsabilité : je ne travaille plus sur les extensions de navigateur sous quelque forme que ce soit, donc mes connaissances sont probablement obsolètes.

L'utilisateur tape a , appelle window.find jusqu'à ce qu'il renvoie NULL . collecter tous les matchs
L'utilisateur tape ab , appelle window.find jusqu'à ce qu'il renvoie NULL . collecter toutes les correspondances, supprimer le précédent

window.find est horrible et devrait être évité autant que possible

• Il s'exécute sur le thread principal, il bloque donc l'entrée de l'utilisateur
• Il a des effets d'interface utilisateur, donc il force également le rendu et bloque davantage l'entrée de l'utilisateur
• Il est basé sur la sélection, donc CSS qui bloque la sélection de texte peut avoir une variété de comportements étranges, selon le navigateur de votre choix
• Il ne s'enroule pas (ou du moins, n'avait pas l'habitude de) s'enrouler dans FF
• C'est en dehors des spécifications et officiellement obsolète, sans intention de standardiser le comportement entre les navigateurs
• Récupérer les données de sélection de cette manière est beaucoup plus coûteux que d'interroger directement le DOM.
  
  
  
  • Comme Dahan le mentionne à juste titre, le vrai surlignage est toujours ignoré, nous devrions donc le collecter pour mettre en évidence plus d'un match.
  
  
  • <input> est difficile de bien extraire ces données de <textarea> , avant même que nous ayons à nous soucier du problème non trivial de la mise en évidence du texte qu'ils contiennent.
  
  

Lorsque j'étais contributeur, nous nous sommes battus pour compter le nombre de résultats de recherche en raison de la lenteur des pages volumineuses. L'utilisation de window.find était d'un ordre de grandeur plus lente et ne fonctionnait pas du tout avec les recherches d'expressions régulières. Je déconseille fortement de l'utiliser pour plus que d'exécuter une seule recherche, et même dans ce cas, cela devrait être un dernier recours.

@gdh1995 Je ne voulais pas utiliser windows.find() cette façon comme vous l'avez dit. Il s'agit simplement de find le texte.
@ mrmr1993 Je comprends que cette fonctionnalité nécessite plus de puissance de calcul ou d'effort humain. Mais au moins, l'utilisateur devrait avoir le choix [option dans la configuration] de le faire en utilisant vimium même si c'est lent du point de vue de l'utilisateur. Quoi qu'il en soit, c'est un peu ennuyeux que parfois Ctrl-F soit utilisé et parfois / soit utilisé et que / ne fonctionne pas comme prévu ( même pas dans vim ).

Y a-t-il autre chose qu'une raison philosophique pour laquelle l'extension ne peut pas simplement autoriser ce type de fonctionnalité, et la ranger dans une section "expérimentale" des paramètres de l'extension, avec des avertissements appropriés en place notant qu'elle peut casser certaines pages ? Cela semble être une demande assez populaire pour qu'il soit logique de l'ajouter ici. J'ai été très satisfait de l'extension " Selection Highlighter " par exemple, malgré le fait qu'elle puisse casser des pages, simplement parce que l'utilitaire l'emporte sur le risque; Je pense que la même chose s'applique ici.

+1 par ici. :)

Je fais écho aux sentiments de macintaco.

J'utilise vimium search en remplacement de l'outil de recherche afin de pouvoir uniformiser les raccourcis clavier sur les différentes installations (toujours utiliser / pour rechercher des éléments).

+1

Firefox a browser.find.find et browser.find.highlightResults . Il ne semble pas prendre en charge les expressions régulières, mais sinon, cela ressemble exactement à ce dont ce problème aurait besoin.

Je voudrais juste noter que SurfingKeys met en évidence les correspondances sur la page via sa fonctionnalité de recherche. Je ne sais pas comment ils le font (cela semble être une sorte de superposition) mais c'est "assez bon" au point que j'utilise cette extension à la place maintenant. YMMV.

+1 - souhaite qu'il y ait au moins une solution de contournement pour cela.

8 années... :)

Récemment, j'ai eu une autre idée : il n'est pas nécessaire de dessiner la couleur de fond de surbrillance, et nous pouvons utiliser des rects de masquage à la place. Par conséquent, j'ai implémenté une version simple dans mon Vimium personnalisé, Vimium C , et il prend en charge Ctrl+J/K pour trouver next/prev et Ctrl+Shift+J/K pour flasher les rects sur toutes les correspondances dans la zone visible actuelle.