"Find" within window contents (similar to Cmd/Ctrl+F on Chrome)

[philrz]

Repro is with Brim commit ab5b75d.

In the attached video, I'm working with the saved query from ciphers.json.gz which contains a const map definition that's over 15k characters wide. I needed to find where an element containing specific text was located and had to cut & paste the editor window's contents into a separate non-Brim editor so i could locate it. As users' Zed programs become more sophisticated these kinds of struggles are likely to come up more often.

Repro.mp4

What I'd have done in this kind of situation in a browser context is invoke the "Find" tool, such as is invoked via Cmd/Ctrl+F in Chrome. Indeed, since Electron shares a lot of its base with Chrome I'd hoped that maybe it was something that could be trivially enabled, but a quick web search revealed an old issue electron/electron#2037 where a spokesperson claimed that's not supported out-of-the-box in Electron. Thankfully as the thread continues people speak as if the API has made it increasingly simple and it looks like there's implementations out there we could borrow from.

[philrz]

I recently discovered accidentally that for the use case originally described here we actually got this functionality "for free" when we started using the Monaco editor (#2824). As shown in the attached video, hitting Cmd-f on macOS brings up the Find tool and I'm able to search for things and see them highlighted within the editor.

Find.mp4

That said, it's not currently mentioned in the drop-down menus, so before we declare victory on this one it seems it could use an entry. Since it only seems to apply to the editor contents, I suppose as we're doing that we should make sure the entry is only active if the user's focus is clicked to the editor and have it be "grayed out" otherwise.

Also, when I opened this and referenced it from #2929, I wasn't yet appreciating that different Find tools might have to be attached to different panels within the app. I imagine users might like it if we could create one Find tool that locates and highlights "hits" in all visible text rendered anywhere in the app, but if that's too hard, then perhaps #2929 could live on as the placeholder for if/when we do something separate for Find within the results.