Improve Ctrl + F 'find' operation UX in built in documentation/script editor

[Kartopod]

The find tool only shows one occurrence of the search term at once. This makes it really difficult to find what you're looking for in a large documentation page with a lot of occurrences of your search term.

Consider this example:

Say I'm looking for a way to set the text of an item in the ItemList class. I just want to quickly see occurrences of the term 'text' in the method list.

• When I search for that term, I'm immediately taken to the first occurrence at the top of the page, which is not helpful at all.
• There are a lot of occurrences that are not relevant, so I'm stuck spamming the down arrow to navigate to where I want to get to.

2025-02-13.14-05-51.mp4

My proposal is to:

• Show the number of the highlighted (primary) match in the context of all the available matches. i.e. Show '1/70 matches' instead of '70 matches' here when the first match is highlighted.
  
• Also highlight ALL other matches with a lighter colour (I'll call these secondary matches for now) or a different tint to differentiate from the 'Primary match' .
  • This allows the user to skim through the whole page quickly, because they can see all occurrences at once.
• Do not scroll all the way up to the first match, highlight the closest match available from where the user currently is.
  • i.e if the user is scrolled somewhere in the middle of the page, they would see the closest match (say) 25th/70 match be highlighted instead of 1/70.
• Clicking on a secondary match should make it the Primary match.
  • This allows the user to click on any other match and continue using the arrows to jump forward or back from that point.
• Selecting any text and then pressing Ctrl + F should automatically put the selected text into the search bar and search for it

[toddcesere]

Ability to find tab characters. \t doesn't work and copying and pasting the tab character doesn't work. Using the tab key takes you to the next field, which is probably correct. You can search for spaces but not tabs.

Godot uses tabs by default and tabs seem to be the common practice for GDScript indentation. I know some people might be tempted to wonder if the difficulty of searching for tab characters is part of a larger problem with using tabs in programming, but we all know to avoid the tabs vs spaces argument. Spaces have issues too. Tabs are fine.

Ability to search for newlines as well.

[arkology]

Show the number of the highlighted (primary) match in the context of all the available matches. i.e. Show '1/70 matches' instead of '70 matches' here when the first match is highlighted.

This is done in godotengine/godot#105968