Vimium: No modo de localização, destaca todas as correspondências na página, não apenas a atual

Não no momento. Acho que aceitaríamos um patch se não causasse um atraso perceptível.

Isso seria um empreendimento bastante grande - supondo que ainda usemos window.find () para realizar a pesquisa, precisaríamos chamá-lo repetidamente para exibir todas as correspondências e, em seguida, mostrar nossa própria IU em destaque.

Se acabarmos passando por esse problema, devemos tirar a estética dos jogos do Safari, IMO.

1 para este recurso.

+1

Vimium é incrível! Esta é a única peça que falta, no que me diz respeito.

1 para este recurso. Na verdade, eu queria sugerir isso, mas tinha aquele sentimento de "não posso ser o único".

Yeyahh!

+1

+1

Se / quando isso for implementado, também seria bom ver todas as correspondências marcadas visualmente na barra de rolagem como o Chromium faz.

+1

Descobri recentemente sobre o vimium, não acredito que não instalei antes.

+1

+1

+1

+1

+1
e acho que esse seria outro recurso matador

+1

PARE de responder com +1 comentários inúteis. isso não acrescenta nada à discussão e vai perder muito tempo das pessoas, pois elas receberão notificações de sua "contribuição" inútil. use a função "assistir" para assinar um ingresso.

+1

+1, o cromo padrão se comporta destacando todos os acertos correspondentes. Se implementá-lo novamente for um problema de desempenho, é possível chamar diretamente a pesquisa do Chrome?

é possível chamar diretamente a pesquisa do Chrome?

Não.

Para implementar algo como isso, seria necessário algo como (um atualizado) # 1081 para que o navegador não travasse em todas as pesquisas, o que aumenta substancialmente a carga de desenvolvimento / manutenção.

Fechando.
Por mais popular que seja, não temos realmente uma maneira de implementar isso.

(Vimium não faz o realce, atualmente. Nós apenas chamamos window.find() .)

4 anos...

+1 Este é realmente um ótimo recurso se puder ser implementado.

Eu fiz algumas pesquisas. Isso parece funcionar http://stackoverflow.com/a/5887719/96100 (a solução inclui o IE, portanto, pode ser ainda mais simplificado removendo a parte do IE)

Mas acho que há uma outra questão - quando e como remover o destaque. Para quando, acho que ao iniciar a próxima pesquisa ou ao executar algo como :noh ; para saber como, presumo que execCommand('undo') faria isso.

Estou realmente ansioso para o recurso.

Isso é necessário e não tenho certeza se é suposto ser um recurso específico do vimium, mas outras extensões do tipo vim fazem isso ( como o surfingkeys, por exemplo ). Já se passaram quase 5 anos e esse recurso ainda não está aqui. O que anda acontecendo no mundo?

Eu fiz algumas pesquisas. Isso parece funcionar http://stackoverflow.com/a/5887719/96100 (a solução inclui o IE, portanto, pode ser ainda mais simplificado removendo a parte do IE)

Esta solução parece envolver modificações inline nos DOMs das páginas, o que me deixa muito desconfortável.

O que anda acontecendo no mundo?

Isso é difícil de fazer corretamente (ou, pelo menos, para minha satisfação).

Uma implementação completa teria que

• encontrar entre os elementos (o que a surfingkeys parece incapaz de fazer; veja aqui e aqui o código deles)
  
  
  
  • por exemplo. encontre e destaque class SuppressPrintable (ou, ainda mais difícil, destaque lass Supp ) nesta página
  
  
  • observe que a linha que nos interessa tem 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>
  
  
  • por exemplo. encontre e destaque testtest em test<img src="#">test , como o achado nativo faz
  
  
  • encontre e destaque testtest em test<input type="text">test (como o Firefox) ou não (como o Chrome).
  
  
• encontre e realce uma string copiada diretamente de uma página. Dois casos se aplicam:
  
  
  
  • o pai tem white-space: normal ou nowrap . test string renderiza como test string , então precisamos encontrar isso. (surfingkeys não pode fazer isso, pois usa node.data )
  
  
  • o pai tem white-space: pre , pre-line ou pre-wrap . test string renderiza como test string , então precisamos encontrar isso
  
  
• encontre elementos que representam espaços em branco (por exemplo, <br /> ou <p></p> ). (as chaves de surf não podem fazer isso)
  
  
  
  • por exemplo. Test<br />Test deve ser encontrado e destacado pesquisando Test\nTest ( ou talvez Test\r\nTest ? )
  
  
  • por exemplo. <p>Test</p><p>Test</p> deve ser encontrado e destacado pesquisando Test\n\nTest (ou Test\r\n\r\nTest )
  
  
• (opcionalmente) encontre e destaque correspondências em <input> s, <textarea> s, <button> s, etc. Este é um grande incômodo para fazer corretamente.

Podemos usar a propriedade innerText para obter uma representação de texto da página, que nos diz a maioria das correspondências (exceto - notavelmente - aquelas mencionadas no último ponto), e quais Vimium usa. No entanto, para destacar (ou mesmo criar uma seleção sem usar window.find ), temos que mapear os resultados da pesquisa de texto (em innerText ) de volta aos intervalos no DOM.

Minha abordagem sugerida (preguiçosa) para isso envolveria uma espécie de busca binária do pobre, criando Range s e usando toString() para mapear em innerText . Não estou particularmente interessado em implementar isso sozinho.

Parece que esse é um recurso altamente desejado, mas talvez todos os requisitos em conjunto sejam grandes demais para serem atendidos. Talvez um conjunto menor de subetapas possa tornar isso mais acessível.

+1

6 anos depois, ainda espero ter esse recurso

• btw, este plugin Chrome Regex Search implementou esta função.
• Seria ótimo se o vimium também pudesse suportar isso.

A extensão Chrome Regex Search usa uma maneira muito perigosa de implementar o recurso de realce e pode quebrar algumas páginas da web normais porque pode quebrar o código JavaScript do host e remover algumas ações de clique.

Parece que não só eu tenho esse problema.

Eu fiz algumas pesquisas. Isso parece funcionar http://stackoverflow.com/a/5887719/96100 (a solução inclui o IE, portanto, pode ser ainda mais simplificado removendo a parte do IE)

Esta solução parece envolver modificações inline nos DOMs das páginas, o que me deixa muito desconfortável.

O que anda acontecendo no mundo?

Isso é difícil de fazer corretamente (ou, pelo menos, para minha satisfação).

Uma implementação completa teria que

• encontrar entre os elementos (o que a surfingkeys parece incapaz de fazer; veja aqui e aqui o código deles)

  • por exemplo. encontre e destaque class SuppressPrintable (ou, ainda mais difícil, destaque lass Supp ) nesta página
  • observe que a linha que nos interessa tem 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>
  • por exemplo. encontre e destaque testtest em test<img src="#">test , como o achado nativo faz
  • encontre e destaque testtest em test<input type="text">test (como o Firefox) ou não (como o Chrome).

• encontre e realce uma string copiada diretamente de uma página. Dois casos se aplicam:

  • o pai tem white-space: normal ou nowrap . test string renderiza como test string , então precisamos encontrar isso. (surfingkeys não pode fazer isso, pois usa node.data )
  • o pai tem white-space: pre , pre-line ou pre-wrap . test string renderiza como test string , então precisamos encontrar isso

• encontre elementos que representam espaços em branco (por exemplo, <br /> ou <p></p> ). (as chaves de surf não podem fazer isso)

  • por exemplo. Test<br />Test deve ser encontrado e destacado pesquisando Test\nTest ( ou talvez Test\r\nTest ? )
  • por exemplo. <p>Test</p><p>Test</p> deve ser encontrado e destacado pesquisando Test\n\nTest (ou Test\r\n\r\nTest )
• (opcionalmente) encontre e destaque correspondências em <input> s, <textarea> s, <button> s, etc. Este é um grande incômodo para fazer corretamente.

Podemos usar a propriedade innerText para obter uma representação de texto da página, que nos diz a maioria das correspondências (exceto - notavelmente - aquelas mencionadas no último ponto), e quais Vimium usa. No entanto, para destacar (ou mesmo criar uma seleção sem usar window.find ), temos que mapear os resultados da pesquisa de texto (em innerText ) de volta aos intervalos no DOM.

Minha abordagem sugerida (preguiçosa) para isso envolveria uma espécie de busca binária do pobre, criando Range s e usando toString() para mapear em innerText . Não estou particularmente interessado em implementar isso sozinho.

Também faço pesquisas sobre window.find (). Apenas destaca o resultado atual na web, não destaca todo o resultado. Talvez chame o método várias vezes? Acho que não é uma boa ideia para esse problema.

que tal essa rotina?

no modo de localização, antes que os usuários pressionem a tecla Enter, apenas chame window.find () uma vez para cada entrada atualizada.

após o uso, pressione a tecla Enter, chame window.find () para mostrar todas as ocorrências.
[possivelmente, para lembrar a posição do resultado encontrado logo antes de entrar]

window.find() sempre destaca a área selecionada "atual", embora nenhum método perfeito para simular o bloco de cores de fundo (por exemplo, se uma linha possuir sua cor / imagem de fundo, então a cor de fundo simulada será invisível).

window.find() sempre destaca a área selecionada "atual", embora nenhum método perfeito para simular o bloco de cores de fundo (por exemplo, se uma linha possuir sua cor / imagem de fundo, então a cor de fundo simulada será invisível).

Oi, deixe-me ser mais claro sobre minha rotina.

Tipo de usuário a , chame window.find até retornar NULL. colete todas as partidas
Tipo de usuário ab , chame window.find até retornar NULL. coletar todas as partidas, cair anterior
Quando usar hit enter , realmente utilize o array de resultados da pesquisa.

@Piping window.find() sempre descarta todas as áreas de destaque antigas e então destaca apenas uma nova, então, na verdade, não há APIs JavaScript para destacar uma lista de áreas.

Isenção de responsabilidade: Eu não trabalho mais com extensões de navegador de nenhuma forma, então meu conhecimento provavelmente está desatualizado.

Tipo de usuário a , chame window.find até que retorne NULL . colete todas as partidas
Tipo de usuário ab , chame window.find até que retorne NULL . coletar todas as partidas, cair anterior

window.find é horrível e deve ser evitado sempre que possível

• Ele é executado no thread principal, portanto, bloqueia a entrada do usuário
• Tem efeitos de IU, então também força a renderização e bloqueia ainda mais a entrada do usuário
• É baseado em seleção, de modo que o CSS que bloqueia a seleção de texto pode ter uma variedade de comportamentos estranhos, dependendo do navegador de sua escolha
• Não (ou pelo menos não costumava) embrulhar em FF
• Está fora das especificações e oficialmente obsoleto, sem intenção de padronizar o comportamento entre os navegadores
• Recuperar os dados de seleção dessa maneira é muito mais caro do que consultar o DOM diretamente.
  
  
  
  • Como Dahan corretamente menciona, o verdadeiro destaque é sempre descartado, então teríamos que coletar isso para destacar mais de 1 correspondência
  
  
  • <input> / <textarea> s são difíceis de extrair bem esses dados, mesmo antes de termos que nos preocupar com o problema não trivial de realçar o texto neles.
  
  

Quando eu era um colaborador, lutávamos para contar o número de resultados de pesquisa por causa da lentidão em páginas grandes. Usar window.find era cerca de uma ordem de magnitude mais lento e não funcionava de forma alguma com pesquisas de expressão regular. Aconselho veementemente não usá-lo para mais do que executar uma única pesquisa e, mesmo assim, deve ser o último recurso.

@ gdh1995 Não pretendia usar windows.find() dessa forma, como você disse. É apenas find o texto.
@ mrmr1993 Eu entendo que esse recurso requer mais capacidade de computação ou esforço do homem. Mas pelo menos o usuário deve ter uma escolha [opção na configuração] para fazer isso usando o vimium, mesmo que seja lento para a perspectiva do usuário. De qualquer forma, é meio chato que às vezes Ctrl-F é usado e às vezes / é usado e / não funciona como esperado (nem mesmo no vim).

Existe algo além de um motivo filosófico pelo qual a extensão não pode simplesmente permitir esse tipo de recurso e colocá-lo em uma seção "experimental" das configurações da extensão, com avisos adequados observando que pode quebrar algumas páginas? Este parece ser um pedido tão popular que faria sentido adicioná-lo aqui. Fiquei muito feliz com a extensão " Selection Highlighter " por exemplo, apesar do fato de que ela pode quebrar páginas, simplesmente porque o utilitário supera o risco; Acho que o mesmo se aplica aqui.

1 por aqui. :)

Eu concordo com os sentimentos do macintaco.

Eu uso o vimium search como um substituto para a ferramenta find para que eu possa manter os atalhos de teclado uniformes em diferentes instalações (sempre use / para encontrar coisas).

+1

O Firefox tem browser.find.find e browser.find.highlightResults . Ele não parece ser compatível com regex, mas parece exatamente o que esse problema precisa.

Gostaria apenas de observar que o SurfingKeys destaca as correspondências na página por meio de sua funcionalidade de pesquisa. Não sei como eles fazem isso (parece ser algum tipo de sobreposição), mas é "bom o suficiente" a ponto de estar usando essa extensão agora. YMMV.

+1 - gostaria que houvesse pelo menos uma solução alternativa para isso.

8 anos... :)

Recentemente, tive outra ideia: não é necessário desenhar a cor de fundo de realce e, em vez disso, podemos usar retificações de máscara. Portanto, implementei uma versão simples em meu Vimium customizado, Vimium C , e ele suporta Ctrl+J/K para encontrar next / prev e Ctrl+Shift+J/K para flashrects em todas as correspondências na área visível atual.