Searches should be able to use the Editor by default

[JacksonKearl]

Currently, the way to use the new Search Editor experience is by first starting a search in either the viewlet or the panel, then copying those results over to an Editor. We should have an option to use the an Editor to begin with.

With this comes some questions:

• How is the Search Editor query modified?
• When should Editors be reused vs. created anew?
• What configuration options should be provided?

This issue will be a staging ground for answering those questions.

Ref #23931.

[alankritjoshi]

some configuration options to explore:

1. whether to open search result in a read only/untitled editor. But this might depend on the design decisions extracted from answering the first two questions in the issue description
2. number of lines pre and post the search string within each result. On other editors like sublime, it's 2 on either end
3. whether to open a search result file on single click/double click. Personally, I don't think cmd + click is intuitive for fast development workflows
4. keyboard shortcut for 3

[JacksonKearl]

New Search Editor implementation is out:

Main Points:

• The Search Editor can be either spawned:
  • From an existing search and the Open In Editor button, as before
  • Using the search.action.openNewEditor command, which, as with search.findInFiles, will seed the query from the current selection if one exists.
    • This command can be mapped to whatever keybinding you want, including Ctrl/Cmd + Shift + F, to use the Search Editor in place of the existing viewlet or panel searches.
    • The viewlet or panel search can be kept around and accessible through click or a different keybinding, or removed from the workbench entirely through the context view on the activity bar or panel.
• The Search Editor's query can be changed using the widget at top of the editor, and will update on type as controlled by the existing search.searchOnType setting.
• There are three new keybindings, toggleSearchEditorWholeWord, toggleSearchEditorRegex, and toggleSearchEditorCaseSensitive, which default to the same keys as their Find Widget/Search viewlet counterparts.
• There is an additional new keybinding, toggleSearchEditorContextLines, which enables or disables showing the lines of context surrounding a result. The default is 2 lines above and below, but this can be modified in the Search Editor.
• A new Search Editor is created each time the search.action.openNewEditor is opened, and this Editor is always pinned.
  • Being pinned means the Search Editor won't be closed when navigating to results that open in the same editor group, but it also may mean that Search Editors will accumulate unless explicitly closed.
• Search results can be navigated on double click, either in the same editor group or to the side. A new setting, search.searchEditorPreview.doubleClickBehaviour controls the behaviour of this, including giving the option to disable this entirely in order to preserve the standard select word on double click functionality. In addition the Go to Definition command will open the result location, and Open Definition to the Side will open the result location in the editor group to the side of the search editor group, creating one if it does not yet exist.
• The Search Editor will not be in a dirty state until the text of the search results has been directly manipulated. This means that there will be no prompt to save on close unless the results have been explicitly modified.

[JacksonKearl]

Still unknown:

• How should I focus back to a previous search editor? Currently the only available command will open a new Editor, should there be a command to cycle through existing ones? Or maybe just use the existing Go Forward and Go Back commands and the Go to File... quick pick?
• How should Focus Next Search Result work?

[adamlogic]

This is fantastic! Some questions as I've been using it today (pretty much all related to me trying to use this feature without a mouse)...

• Is there a command for the double-click behavior (so I can open a result with the keyboard)?
• Is it intentional to focus on the query when the search tab regains focus? This makes it difficult when I'm using my keyboard to navigate results.
• Is it intentional to not persist search options (regex, case sensitive) like the sidebar search does?
• Is it intentional to not live-update search results like the sidebar does? If so, is there a command to re-run the search (so I can trigger via keyboard while focused in the results rather than the query)?

Happy to create issues for any or all of these. I only discovered this work yesterday, so I'm really not sure what's intentional and what's an issue.

Thanks so much for your work on this!

[JacksonKearl]

@adamlogic thanks for the feedback!

Is there a command for the double-click behavior (so I can open a result with the keyboard)?

Yes you can use Go to Definition and Open Definition to the Side, which are F12 and Option + F12 I believe.

Is it intentional to focus on the query when the search tab regains focus? This makes it difficult when I'm using my keyboard to navigate results.

I'm currently working on maintaining the editor state when you switch between editors, that should be out in the next insiders (Monday).

Is it intentional to not persist search options (regex, case sensitive) like the sidebar search does?

This one is interesting. You're opening a "new search", so it would make sense that the old search's settings aren't used, but it is also sometimes nice to be able to set particular file globs/etc. and have those persist across searches. I'm not sure what the right answer is here.

Is it intentional to not live-update search results like the sidebar does? If so, is there a command to re-run the search (so I can trigger via keyboard while focused in the results rather than the query)?

No, it should be live-reloading, is it not for you? Edit: Never mind, I see what you mean. Yes it's intentional that we don't track the files right now. I will add a rerun search command.

[JacksonKearl]

@adamlogic Search: Rerun Search in Editor will be available in the next Insiders. It is unbound currently but you could bind it to whatever using the Keybindings Editor.

[adamlogic]

@JacksonKearl Thanks for all of that! Go To Definition works great. I didn't see it in the command palette, but F12 worked, and I was able to remap it.

You're opening a "new search", so it would make sense that the old search's settings aren't used, but it is also sometimes nice to be able to set particular file globs/etc. and have those persist across searches. I'm not sure what the right answer is here.

Exactly. I'm not so interested in persisting the options across searches as I'm interested in setting some defaults. I almost always want to search with regular expressions, so it'd great if I had the option to make that the default.

Search: Rerun Search in Editor will be available in the next Insiders. It is unbound currently but you could bind it to whatever using the Keybindings Editor.

Perfect! If I want a keybinding that's only used in these search results, is there a boolean I could use in the when portion of a keybinding definition? (searchEditorResultsFocus or something like that?)

[JacksonKearl]

Perfect! If I want a keybinding that's only used in these search results, is there a boolean I could use in the when portion of a keybinding definition? (searchEditorResultsFocus or something like that?)

inSearchEditor should be what you want, let me know if it works as expected. It's what we use for the search editor toggle regex/etc. keybindings too.

Exactly. I'm not so interested in persisting the options across searches as I'm interested in setting some defaults. I almost always want to search with regular expressions, so it'd great if I had the option to make that the default.

If you could open a new issue for this we can continue discussion there.