Vimium: En el modo de búsqueda, resalte todas las coincidencias en la página, no solo la actual

No en este momento. Creo que aceptaríamos un parche si no causara un retraso notable.

Esta sería una empresa bastante grande: asumiendo que todavía usamos window.find () para realizar la búsqueda, tendríamos que llamarlo repetidamente para mostrar todas las coincidencias y luego mostrar nuestra propia interfaz de usuario resaltada.

Si terminamos pasando por ese problema, deberíamos copiar la estética de los partidos de Safari, en mi opinión.

+1 para esta función.

+1

¡Vimium es increíble! Esta es la única pieza que falta en lo que a mí respecta.

+1 para esta función. De hecho, quería sugerir esto yo mismo, pero tenía ese sentimiento de "no puedo ser el único".

¡Yeyahh!

+1

+1

Si / cuando esto se implemente, también sería bueno ver todas las coincidencias marcadas visualmente en la barra de desplazamiento como lo hace Chromium.

+1

Descubrí recientemente vimium, no puedo creer que no lo haya instalado antes.

+1

+1

+1

+1

+1
y creo que esta sería otra característica genial

+1

DEJE de responder con comentarios +1 inútiles. no agrega nada a la discusión, y hará perder mucho tiempo a la gente, ya que recibirán notificaciones de su "contribución" inútil. use la función "mirar" para suscribirse a un boleto.

+1

+1, el cromo predeterminado se comporta resaltando todos los resultados coincidentes. Si implementarlo nuevamente sería un problema de rendimiento, ¿es posible llamar directamente a la búsqueda de Chrome?

¿Es posible llamar directamente a la búsqueda de Chrome?

No.

Para implementar algo como esto, se necesitaría algo como (un actualizado) # 1081 para que el navegador no se cuelgue en cada búsqueda, lo que aumenta sustancialmente la carga de desarrollo / mantenimiento.

Clausura.
Por muy popular que sea, realmente no tenemos una forma de implementar esto.

(Actualmente, Vimium no hace el resaltado en absoluto. Solo llamamos window.find() ).

4 años...

+1 Esta es realmente una gran característica si se puede implementar.

Investigué un poco. Esto parece hacerlo http://stackoverflow.com/a/5887719/96100 (la solución incluye IE, por lo que se puede simplificar aún más eliminando la parte de IE)

Pero creo que hay una pregunta adicional: cuándo y cómo eliminar el resaltado. Para cuándo, pienso al comenzar la siguiente búsqueda o al ejecutar algo como :noh ; por cómo, supongo que execCommand('undo') lo haría.

Realmente espero con ansias la función.

Esto es necesario y no estoy seguro de si se supone que sea una característica específica de vimium, pero otras extensiones similares a vim hacen esto ( como surfingkeys, por ejemplo ). Ya han pasado casi 5 años y esta función aún no está aquí. ¿Qué sucede?

Investigué un poco. Esto parece hacerlo http://stackoverflow.com/a/5887719/96100 (la solución incluye IE, por lo que se puede simplificar aún más eliminando la parte de IE)

Esta solución parece implicar modificaciones en línea en los DOM de las páginas, lo que me incomoda mucho.

¿Qué sucede?

Esto es difícil de hacer correctamente (o, al menos, para mi satisfacción).

Una implementación completa tendría que

• buscar elementos (que surfingkeys parece incapaz de hacer; consulte aquí y aquí su código)
  
  
  
  • p.ej. busque y resalte class SuppressPrintable (o, aún más difícil, resalte lass Supp ) en esta página
  
  
  • tenga en cuenta que la línea que nos interesa tiene 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>
  
  
  • p.ej. buscar y resaltar testtest en test<img src="#">test , como lo hace la búsqueda nativa
  
  
  • busque y resalte testtest en test<input type="text">test (como Firefox) o no (como Chrome).
  
  
• busque y resalte una cadena copiada directamente de una página. Se aplican dos casos:
  
  
  
  • el padre tiene white-space: normal o nowrap . test string representa como test string , por lo que necesitamos encontrar eso. (surfingkeys no puede hacer esto, ya que usa node.data )
  
  
  • el padre tiene white-space: pre , pre-line o pre-wrap . test string representa como test string , por lo que necesitamos encontrar eso
  
  
• busque elementos que representen espacios en blanco (por ejemplo, <br /> o <p></p> ). (surfingkeys no puede hacer esto)
  
  
  
  • p.ej. Test<br />Test debe encontrar y resaltar buscando Test\nTest ( o quizás Test\r\nTest ? )
  
  
  • p.ej. <p>Test</p><p>Test</p> debe encontrar y resaltar buscando Test\n\nTest (o Test\r\n\r\nTest )
  
  
• (opcionalmente) busque y resalte coincidencias en <input> s, <textarea> s, <button> s, etc. Esto es una molestia importante para hacerlo correctamente.

Podemos usar la propiedad innerText para obtener una representación de texto de la página, que nos dice la mayoría de las coincidencias (excepto, en particular, las mencionadas en la última viñeta) y que usa Vimium. Sin embargo, para resaltar (o incluso crear una selección sin usar window.find ), tenemos que mapear los resultados de la búsqueda de texto (en innerText ) nuevamente en rangos en el DOM.

Mi enfoque sugerido (perezoso) para eso implicaría una especie de búsqueda binaria del pobre, creando Range s , y usando toString() para mapear en innerText . No estoy particularmente interesado en implementar esto yo mismo.

Parece que esta es una característica muy deseada, pero quizás todos los requisitos tomados en conjunto sean demasiado grandes para abordarlos. Quizás un conjunto más pequeño de subpasos podría hacer que esto sea más accesible.

+1

6 años después, todavía espero tener esta función.

• Por cierto, este complemento Chrome Regex Search implementó esta función.
• Sería genial si vimium también pudiera admitir esto.

La extensión Chrome Regex Search utiliza una forma muy peligrosa de implementar la función de resaltado y puede romper algunas páginas web normales porque podría descomponer el código JavaScript del host y eliminar algunas acciones de clic.

Parece que no solo yo tengo este problema.

Investigué un poco. Esto parece hacerlo http://stackoverflow.com/a/5887719/96100 (la solución incluye IE, por lo que se puede simplificar aún más eliminando la parte de IE)

Esta solución parece implicar modificaciones en línea en los DOM de las páginas, lo que me incomoda mucho.

¿Qué sucede?

Esto es difícil de hacer correctamente (o, al menos, para mi satisfacción).

Una implementación completa tendría que

• buscar elementos (que surfingkeys parece incapaz de hacer; consulte aquí y aquí su código)

  • p.ej. busque y resalte class SuppressPrintable (o, aún más difícil, resalte lass Supp ) en esta página
  • tenga en cuenta que la línea que nos interesa tiene 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>
  • p.ej. buscar y resaltar testtest en test<img src="#">test , como lo hace la búsqueda nativa
  • busque y resalte testtest en test<input type="text">test (como Firefox) o no (como Chrome).

• busque y resalte una cadena copiada directamente de una página. Se aplican dos casos:

  • el padre tiene white-space: normal o nowrap . test string representa como test string , por lo que necesitamos encontrar eso. (surfingkeys no puede hacer esto, ya que usa node.data )
  • el padre tiene white-space: pre , pre-line o pre-wrap . test string representa como test string , por lo que necesitamos encontrar eso

• busque elementos que representen espacios en blanco (por ejemplo, <br /> o <p></p> ). (surfingkeys no puede hacer esto)

  • p.ej. Test<br />Test debe encontrar y resaltar buscando Test\nTest ( o quizás Test\r\nTest ? )
  • p.ej. <p>Test</p><p>Test</p> debe encontrar y resaltar buscando Test\n\nTest (o Test\r\n\r\nTest )
• (opcionalmente) busque y resalte coincidencias en <input> s, <textarea> s, <button> s, etc. Esto es una molestia importante para hacerlo correctamente.

Podemos usar la propiedad innerText para obtener una representación de texto de la página, que nos dice la mayoría de las coincidencias (excepto, en particular, las mencionadas en la última viñeta) y que usa Vimium. Sin embargo, para resaltar (o incluso crear una selección sin usar window.find ), tenemos que mapear los resultados de la búsqueda de texto (en innerText ) nuevamente en rangos en el DOM.

Mi enfoque sugerido (perezoso) para eso implicaría una especie de búsqueda binaria del pobre, creando Range s , y usando toString() para mapear en innerText . No estoy particularmente interesado en implementar esto yo mismo.

También investigo un poco sobre window.find (). Solo resalta el resultado actual en la web, no resalta todo el resultado. ¿Quizás llamar al método varias veces? Creo que no es una buena idea para este tema.

¿Qué tal esta rutina?

en el modo de búsqueda, antes de que los usuarios presionen la tecla Intro, solo llame a window.find () una vez por cada entrada actualizada.

después de su uso, presione la tecla Intro, llame a window.find () para mostrar todas las apariciones.
[posiblemente, para recordar la posición del resultado de búsqueda justo antes de ingresar]

window.find() siempre resalta el área seleccionada "actual", mientras que no hay un método perfecto para simular el bloque de color de fondo (por ejemplo, si una línea tiene su color / imagen de fondo, entonces el color de fondo simulado será invisible).

window.find() siempre resalta el área seleccionada "actual", mientras que no hay un método perfecto para simular el bloque de color de fondo (por ejemplo, si una línea tiene su color / imagen de fondo, entonces el color de fondo simulado será invisible).

Hola, déjame ser más claro sobre mi rutina.

Tipo de usuario a , llame a window.find hasta que devuelva NULL. recoger todos los partidos
Tipo de usuario ab , llame a window.find hasta que devuelva NULL. recoger todas las coincidencias, soltar las anteriores
Cuando use presione enter , en realidad utilice la matriz de resultados de búsqueda.

@Piping window.find() siempre elimina todas las áreas de resaltado antiguas y luego solo resalta una nueva, por lo que, de hecho, no hay API de JavaScript para resaltar una lista de áreas.

Descargo de responsabilidad: Ya no trabajo en extensiones de navegador de ninguna forma, por lo que es probable que mi conocimiento esté desactualizado.

Tipo de usuario a , llame a window.find hasta que devuelva NULL . recoger todos los partidos
Tipo de usuario ab , llame window.find hasta que devuelva NULL . recoger todas las coincidencias, soltar las anteriores

window.find es horrible y debe evitarse siempre que sea posible

• Se ejecuta en el hilo principal, por lo que bloquea la entrada del usuario.
• Tiene efectos de interfaz de usuario, por lo que también fuerza la renderización y bloquea aún más la entrada del usuario.
• Se basa en la selección, por lo que CSS que bloquea el texto para que no se seleccione puede tener una variedad de comportamientos extraños, según el navegador que elija.
• No se ajusta (o al menos no solía hacerlo) en FF
• Está fuera de las especificaciones y oficialmente en desuso, sin intención de estandarizar el comportamiento entre navegadores.
• Recuperar los datos de selección de esta manera es mucho más costoso que consultar el DOM directamente.
  
  
  
  • Como Dahan menciona correctamente, el verdadero resaltado siempre se descarta, por lo que tendríamos que recopilarlo para resaltar más de 1 coincidencia.
  
  
  • <input> / <textarea> s son difíciles de sacar bien de estos datos, incluso antes de que tengamos que preocuparnos por el problema no trivial de resaltar texto en ellos.
  
  

Cuando era colaborador, luchamos por contar el número de resultados de búsqueda debido a lo lento que era en páginas grandes. El uso de window.find fue aproximadamente un orden de magnitud más lento y no funcionó en absoluto con las búsquedas de expresiones regulares. Recomiendo encarecidamente no usarlo para más que para ejecutar una sola búsqueda, e incluso entonces debería ser un último recurso.

@ gdh1995 No quise usar windows.find() esa manera como dijiste. Es simplemente find el texto.
@ mrmr1993 Entiendo que esta función requiere más potencia de cálculo o esfuerzo humano. Pero al menos el usuario debería tener una opción [opción en la configuración] para hacer esto usando vimium incluso si es lento para la perspectiva del usuario. De todos modos, es un poco molesto que a veces se use Ctrl-F y a veces se use / y / no funcione como se esperaba (ni siquiera en vim).

¿Hay algo más que una razón filosófica por la que la extensión no puede permitir este tipo de función y colocarla en una sección "experimental" de la configuración de la extensión, con las advertencias adecuadas en el lugar señalando que puede romper algunas páginas? Esto parece una solicitud lo suficientemente popular como para que tenga sentido agregarlo allí. Me ha gustado bastante la extensión " Selection Highlighter ", por ejemplo, a pesar de que puede romper páginas, simplemente porque la utilidad supera el riesgo; Creo que lo mismo se aplica aquí.

+1 por aquí. :)

Me hago eco de los sentimientos de macintaco.

Utilizo la búsqueda de vimium como reemplazo de la herramienta de búsqueda para poder mantener uniformes los atajos de teclado en diferentes instalaciones (siempre use / para buscar cosas).

+1

Firefox tiene browser.find.find y browser.find.highlightResults . No parece admitir expresiones regulares, pero por lo demás parece exactamente lo que necesitaría este problema.

Solo me gustaría señalar que SurfingKeys resalta las coincidencias en la página a través de su función de búsqueda. No sé cómo lo hacen (parece ser una especie de superposición) pero es "lo suficientemente bueno" hasta el punto de que ahora estoy usando esa extensión. YMMV.

+1 - Ojalá hubiera al menos una solución para esto.

8 años... :)

Recientemente se me ocurrió otra idea: no es necesario dibujar el color de fondo resaltado, y podemos usar rectos de enmascaramiento en su lugar. Por lo tanto, he implementado una versión simple en mi Vimium personalizado, Vimium C , y admite Ctrl+J/K para buscar siguiente / anterior y Ctrl+Shift+J/K para flashear las reacciones en todas las coincidencias en el área visible actual.