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.

[adamlogic]

@JacksonKearl 👍 #89353

[carlocardella]

Thanks, this looks very promising.
Still in term of keyboard navigation, I am trying to add a keybinding to show the search advanced options, like this:

{
    "key": "ctrl+shift+j",
    "command": "workbench.action.search.toggleQueryDetails",
    "when": "searchViewletVisible || inSearchEditor"
},
{
    "key": "ctrl+shift+j",
    "command": "-workbench.action.search.toggleQueryDetails",
    "when": "searchViewletVisible"
}

This is the same behavior as in the search viewlet, should this work? I can open a new bug for tracking if needed

[JacksonKearl]

@carlocardella Yes please make a separate issue, thanks!

[carlocardella]

@JacksonKearl #89536
thanks

[JacksonKearl]

Closing out as the initial goal, providing a way to use the Search Editor by default, has been completed. The command search.action.openNewEditor can be assigned to either what workbench.action.findInFiles had been to use the search editor instead of viewlet/panel search, or given a new keybinding to use both concurrently.

In addition, it can be triggered using the command pallet (Search: Open New Search Editor) for one-time-use cases.

[karlhorky]

This is great, thanks Jackson! I assume this is currently in Insiders Edition and will roll out with the February or March update for non-Insiders users?

[JacksonKearl]

This is currently in Insiders enabled by default. It will be in the January Stable, but behind feature flag search.enableSearchEditorPreview, which can be toggled in the settings editor.

[gosku]

@JacksonKearl this is helping a lot. Thank you very much for the hard work. Searching is one of the most important parts in an editor and you just made VSC a serious alternative for a lot of developers.

Is it possible to focus on the search editor's results using a shortcut? I got lost in this step:

1. I use shortcut to open new search editor.
2. The search editor starts focused on the query form, so I type what I want to find project-wise. While I type I can see the results updating.
3. When I have the results I want, How do I focus on the results, so I can move the cursor and select the desired result to Go to the definition?

[JacksonKearl]

The existing command search.focus.nextInputBox will work in search editors as well as viewlet search. This is bound to ctrl/Cmd+Down by default I believe.

[JosephTLyons]

I just found out about this feature a few days back and am entirely excited for it. I've checked 1.41's preliminary experimental version and I'm currently looking at the insider's edition (1.42) version of it. Just wanted to say that this looks like it will be amazing. I know it is still in development, but I just wanted to ask a question:

Is there any plan to allow us to be able to remove search results from the list? If so, I would love to make a suggestion. Currently, in the sidebar search, when you dismiss a search result (or a group of search results), you cannot undo that action with a cmd/control-Z. If this new search were to implement the feature of being able to dismiss certain search results, it would be great if that action was undoable. A lot of times, I will do my best to filter down the search results using regula expressions, but I still have to manually remove results. I often accidentally remove one I don't want to remove, then I have to start the search over from scratch, removing results I didn't need. Being able to undo a dismissed search result (or group of results) would be awesome.

[JacksonKearl]

@JosephTLyons yes the results are displayed in an editor the same as any other editor in the application. You can edit them and undo/redo as you would any other document.

[rublev]

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.

Is this already in vscode? Which release? I'm using vscodium so don't have access to bleeding edge releases.

[JacksonKearl]

@rublev it has been in vscode since 1.41. Most/all QOL features are missing until 1.42. It gets actually pleasant in 1.43 (insiders).

[rublev]

@rublev it has been in vscode since 1.41. Most/all QOL features are missing until 1.42. It gets actually pleasant in 1.43 (insiders).

@JacksonKearl Ah I'm on 1.42.1 VSCodium. So this expanded style search like sublime in the reply I quoted above is only available once 1.43 gets published (or whatever the correct word is)?

edit: got it working, just wondering how to add the dimmed context lines around it. I toggled the option with cmd+alt+L in the search editor but the lines aren't dimmed.

I also notice that if context is enabled, and i press f12 on a search result then in the sidebar of definitions in the popup there are definitions that do not include the matched search text, but also the context lines around it.

[JacksonKearl]

just wondering how to add the dimmed context lines around it. I toggled the option with cmd+alt+L in the search editor but the lines aren't dimmed.

The lines should be dimmed by default, I've seen cases where they don't dim until the editor gets focus, but not cases where they don't dim at all.

I also notice that if context is enabled, and i press f12 on a search result then in the sidebar of definitions in the popup there are definitions that do not include the matched search text, but also the context lines around it.

I'm not sure what you mean by this. Please open a separate issue with screenshots and reproduction step.

[JosephTLyons]

I actually didn't even know that the lines would dim, as I don't think it has ever happened on my side. They do not dim for me by default unless I run cmd+option+L, as previously mentioned. I was struggling to separate some of these lines out before, this is a big help. It would be great if the code was also dimmed on those lines as well.

[JosephTLyons]

I really am enjoying this feature, thank you a ton for your work here, it is greatly appreciated. There are a few things that I would love to have:

1. The ability to remove a search result, as we have in the sidebar search.
2. The ability to undo the removal of a search result, which is something I don't think the sidebar search has, which always sort of bothered me (I'd accidentally remove a search result I needed and didn't know how to get it back without running the whole search again and sifting through all the results)
3. A way to collapse search results

I realize that this is all inside of an editor, so I'm not sure actually what is possible, but these are just a few things I would love to have.

[JacksonKearl]

@JosephTLyons you can delete and undo as you would in an editor. Delete Line is Cmd+Shift+K, if you want you could bind that to just Backspace when in a search editor. It would be nice if the the file name line would delete along with the last line from that file, and if context lines deleted with their owning lines. Feel free to open a feature request to discuss that further.

You can collapse results with standard folding operations. This works best in Insiders.

[JacksonKearl]

I don't think it has ever happened on my side. They do not dim for me by default unless I run cmd+option+L, as previously mentioned.

Thats interesting, so if you trigger context lines with keybinding they dim, but if you trigger with the button they don't? Does that reproduce in Insiders?

It would be great if the code was also dimmed on those lines as well.

We can't do this by default for accessibility reasons (I know we already do it for unused code, but I disagree with that 😉). It could be an option though. Again feel free to open a feature request to discuss further.

[spacesuitdiver]

Am I missing some magic sauce binding to get the search to trigger when you activate the keyboard shortcut? It puts the selection into the search but doesn't trigger the search.

[JacksonKearl]

@spacesuitdiver do you have search.searchOnType disabled?

[spacesuitdiver]

@JacksonKearl I don’t, I can type a space after the word and search commences.

[JacksonKearl]

@JacksonKearl this is fixed on Insiders

[spacesuitdiver]

Something else that seems off or should be configurable is the fact that it opens a preview (unpinned) window. If I have to double click on the result in the find it should probably pin the editor.

[JacksonKearl]

@spacesuitdiver in which cases does it open unpinned for you? It should be pinned in almost all cases (the exception being when you open a saved search editor from disk).

[spacesuitdiver]

@JacksonKearl I would want this to open pinned already.

[JacksonKearl]

@spacesuitdiver what is the use case for that opening pinned by default?

[spacesuitdiver]

@JacksonKearl I guess my most compelling reasoning is it feels as if it should pin because you are double clicking it. This is also this is how Sublime Text operates.

[JacksonKearl]

We're not looking to mirror every little detail of how Sublime operates. Without a concrete and compelling use case I don't think this will be added.

[spacesuitdiver]

Don't get hung up on my desire to want feature parity of Sublime Text, I gave up on that when VS Code marked this issue "as designed" 😆#29376.

Again, as I said, my most compelling reasoning is it should behave similar to the file explorer, if you doubleclick you are pinning it.