Prevent UI hangs in find and replace / go to line processing

[WebCoder49]

Typing some text to find and replace or a line number to go to can cause slowness now and make the next keystroke not be displayed for a while, so the processing to find and highlight text or find line length should not be carried out for every fast keystroke. Debounce it like this or with the requestAnimationFrame method used in code-input.js core.

This will probably require added timeouts for the findandreplace/gotoline tests.

[WebCoder49]

In the find and replace plugin, debouncing is already implemented, as is limiting of the number of displayed matches (const CODE_INPUT_FIND_AND_REPLACE_MATCH_BLOCK_SIZE). There are two further actions that can be taken:

• (Good option, potentially together with the bad option for a better option) Change the match-displaying algorithm so it does not highlight each match separately but rather sweeps through all at once (changes time complexity from O((n+d)m) to O(n+dm), where n is the length of the code, d is the depth of the syntax-highlighting tree and m is the number of matches).
• (Bad option; use only if necessary) Increase the debouncing interval, and decrease the number of displayed matches. Leads to slightly worse user experience.

[WebCoder49]

The match-displaying algorithm will also be a good foundation for the selective-highlighting performance improvements.

[WebCoder49]

• (Good option, potentially together with the bad option for a better option) Change the match-displaying algorithm so it does not highlight each match with a separate traversal of the highlighting elements, but rather sweeps through all at once (changes time complexity from O((n+d)m) to O(n+dm), where n is the length of the code, d is the depth of the syntax-highlighting tree and m is the number of matches).

An (incomplete - the newline styling isn't handled yet) implementation of this is in the faster-find-highlighting branch but it doesn't provide any visible speedup for searching for "e" in code-input.js source code, in Prism.js or highlight.js.

Perhaps using TreeWalker instead of .nextSibling, .firstChild, .parentNode etc. will speed it up? Slightly harder when the DOM tree changes, though.

[WebCoder49]

A breaking change method would be to use Autocomplete-plugin-like absolutely-positioned overlays, separate to both the editing and highlighting elements, rather than spans inside the highlighting element.