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

Activity

1. WebCoder49

   added

   area:existing-pluginA bug/feature for an existing plugin in the plugins folder of code-input.A bug/feature for an existing plugin in the plugins folder of code-input.

   area:testsExtra required/suggested tests for code-input and/or its plugins, in the tests folder.Extra required/suggested tests for code-input and/or its plugins, in the tests folder.

   priority:high

   good first issueGood for newcomersGood for newcomers

   on Nov 6, 2025
2. WebCoder49

   changed the title [-]Debounce find and replace / go to line processing[/-] [+]Prevent UI hangs in find and replace / go to line processing[/+] on Nov 15, 2025
3. WebCoder49 commented on Nov 15, 2025

   

   WebCoder49

   on Nov 15, 2025

   Last edited by WebCoder49

   OwnerAuthor

   More actions

   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.
4. WebCoder49

   removed

   good first issueGood for newcomersGood for newcomers

   on Nov 17, 2025
5. WebCoder49 commented on Dec 7, 2025

   

   WebCoder49

   on Dec 7, 2025

   OwnerAuthor

   More actions

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

   added

   bugSomething isn't workingSomething isn't working

   and removed

   area:testsExtra required/suggested tests for code-input and/or its plugins, in the tests folder.Extra required/suggested tests for code-input and/or its plugins, in the tests folder.

   on Mar 16, 2026
7. WebCoder49

   self-assigned this

   on Mar 17, 2026
8. WebCoder49 commented on Mar 18, 2026

   

   WebCoder49

   on Mar 18, 2026

   Last edited by WebCoder49

   OwnerAuthor

   More actions

   • (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.
9. WebCoder49 commented on Mar 18, 2026

   

   WebCoder49

   on Mar 18, 2026

   OwnerAuthor

   More actions

   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.