Vimium: В режиме поиска выделите все совпадения на странице, а не только текущий

Не в данный момент. Думаю, мы бы согласились с патчем, если бы он не вызывал заметных задержек.

Это будет довольно сложная задача - предполагая, что мы все еще используем window.find () для выполнения поиска, нам нужно будет вызывать его несколько раз, чтобы отображать все совпадения, а затем отображать наш собственный пользовательский интерфейс выделения.

Если мы в конечном итоге столкнемся с этой проблемой, мы должны избавиться от эстетики совпадений Safari, ИМО.

+1 за эту функцию.

+1

Вимиум потрясающий! Насколько я понимаю, это единственный недостающий элемент.

+1 за эту функцию. Я действительно хотел предложить это сам, но у меня было чувство «я не могу быть единственным».

Даааааааааааааааааааааааа!

+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)

Это решение, похоже, включает в себя встроенные модификации DOM страниц, что меня очень неудобно.

Что происходит в мире?

Это сложно сделать должным образом (или, по крайней мере, к моему удовлетворению).

Полная реализация должна

• находить среди элементов (которые, похоже, не могут сделать клавиши серфинга; их код см. здесь и здесь )
  
  
  
  • например. найти и выделить 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 , как это делает собственный find
  
  
  • либо найдите и выделите testtest в test<input type="text">test (например, Firefox) или не делайте этого (например, Chrome).
  
  
• найти и выделить строку, скопированную прямо со страницы. Применяются два случая:
  
  
  
  • у родителя есть white-space: normal или nowrap . test string отображается как test string , поэтому нам нужно это найти. (клавиши серфинга не могут этого сделать, так как он использует 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)

Это решение, похоже, включает в себя встроенные модификации DOM страниц, что меня очень неудобно.

Что происходит в мире?

Это сложно сделать должным образом (или, по крайней мере, к моему удовлетворению).

Полная реализация должна

• находить среди элементов (которые, похоже, не могут сделать клавиши серфинга; их код см. здесь и здесь )

  • например. найти и выделить 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 , как это делает собственный find
  • либо найдите и выделите testtest в test<input type="text">test (например, Firefox) или не делайте этого (например, Chrome).

• найти и выделить строку, скопированную прямо со страницы. Применяются два случая:

  • у родителя есть white-space: normal или nowrap . test string отображается как test string , поэтому нам нужно это найти. (клавиши серфинга не могут этого сделать, так как он использует 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. собрать все совпадения, отбросить предыдущие
При использовании hit enter фактически используется массив результатов поиска.

@Piping window.find() всегда удаляет все старые области выделения, а затем выделяет только одну новую, так что на самом деле нет API JavaScript для выделения списка областей.

Отказ от ответственности: я больше не работаю над расширениями браузера ни в какой форме, поэтому мои знания, вероятно, устарели.

Пользователь вводит a , вызывает window.find пока он не вернет NULL . собрать все спички
Пользователь вводит ab , вызывает window.find пока он не вернет NULL . собрать все совпадения, отбросить предыдущие

window.find - это ужасно, и его следует по возможности избегать

• Он работает в основном потоке, поэтому блокирует ввод данных пользователем.
• Он имеет эффекты пользовательского интерфейса, поэтому он также принудительно выполняет рендеринг и дополнительно блокирует ввод данных пользователем.
• Он основан на выделении, поэтому CSS, блокирующий выделение текста, может вести себя по-разному, в зависимости от выбранного вами браузера.
• Он не (или, по крайней мере, не привык) переносится в FF
• Это вне спецификации и официально не рекомендуется, без намерения стандартизировать поведение между браузерами.
• Получение данных выбора таким способом намного дороже, чем прямой запрос к DOM.
  
  
  
  • Как правильно отмечает Дахан, истинное выделение всегда отбрасывается, поэтому нам придется собирать его, чтобы выделить более 1 совпадения.
  
  
  • <input> / <textarea> трудно получить эти данные из колодца, даже до того, как нам придется беспокоиться о нетривиальной проблеме выделения в них текста.
  
  

Когда я был соавтором, мы боролись за подсчет количества результатов поиска из-за того, насколько медленными они были на больших страницах. Использование window.find было примерно на порядок медленнее и вообще не работало с поиском по регулярным выражениям. Я настоятельно не рекомендую использовать его больше, чем для выполнения одного поиска, и даже в этом случае это должно быть крайней мерой.

@ gdh1995 Я не собирался использовать windows.find() таким образом, как вы сказали. Это просто find текст.
@ mrmr1993 Я понимаю, что эта функция требует больше вычислительных мощностей или человеческих усилий. Но, по крайней мере, у пользователя должен быть выбор [опция в конфигурации], чтобы сделать это с помощью vimium, даже если это медленно с точки зрения пользователя. В любом случае, это немного раздражает, что иногда используется Ctrl-F, а иногда используется /, и / не работает должным образом (даже в vim).

Есть ли какая-то другая причина, кроме философской, почему расширение не может просто разрешить этот тип функции и поместить ее в «экспериментальный» раздел настроек расширения с соответствующими предупреждениями о том, что это может сломать некоторые страницы? Это кажется достаточно популярным запросом, чтобы иметь смысл добавить его туда. Я был вполне доволен, например, расширением « Selection Highlighter », несмотря на то, что оно могло сломать страницы просто потому, что утилита перевешивает риск; Думаю, здесь то же самое.

+1 здесь. :)

Я разделяю мнение Макинтако.

Я использую поиск vimium как замену инструменту поиска, так что я могу сохранить единообразие сочетаний клавиш для разных установок (всегда используйте / для поиска).

+1

В Firefox есть browser.find.find и browser.find.highlightResults . Похоже, что он не поддерживает регулярное выражение, но в остальном выглядит именно так, как требуется для этой проблемы.

Я просто хотел бы отметить, что SurfingKeys выделяет совпадения на странице с помощью функции поиска. Я не знаю, как они это делают (похоже, это какой-то оверлей), но он «достаточно хорош» в том смысле, что сейчас я использую это расширение. YMMV.

+1 - хотелось бы, чтобы для этого было хотя бы обходное решение.

8 лет... :)

Недавно у меня возникла еще одна идея: рисовать цвет фона подсветки необязательно, можно использовать вместо этого прямоугольники маскировки. Поэтому я реализовал простую версию в моем настроенном Vimium, Vimium C , и она поддерживает Ctrl+J/K для поиска следующего / предыдущего и Ctrl+Shift+J/K для мигания прямоугольников для всех совпадений в текущей видимой области.