Vscode: Search: often loosing my results when switching views

Created on 19 Feb 2020  路  13Comments  路  Source: microsoft/vscode

Marking as important because this is frustrating. I spend 2 hours going through a long search result, removing individual items and then clicked on Explorer and back to Search. Somehow the text I selected in the editor ran a new search automatically and I cannot go back to my previous result?

bug important search verified

All 13 comments

Looks like #87217.
I would love to see it really it resolved, because:

  1. Click on X or single Delete is much faster then Search Editor (need to manually remove path if all results removed)
  2. Simple navigation with arrows trigger file preview so I can see more context then Search editor (editor has context lines, but then I need to manually remove even more lines)

@roblourens Clicking on the search viewlet has replaced the query with the editor's selection since 1.40 at least. With searchOnType that now runs the query.

Potential fixes:

  • Clicking on the viewlet doesn't seed query from editor selection. This makes some sense, but the keybinding and the click should have the same behaviour, and the keybinding should seed with the selection.
  • Selection-seeded queries don't trigger new searches. I believe this was 1.41's behaviour but I'm not sure. It's a bit odd to require Enter only sometimes, and it still has the issue that if you press up to go to the old query it will re-run the search
  • We special case "dirty" search results to disable searchOnType entirely. I think this makes the most sense, at least as an option.

Clicking on the viewlet doesn't seed query from editor selection. This makes some sense, but the keybinding and the click should have the same behaviour, and the keybinding should seed with the selection.

Not sure why click on search tab should trigger new search.
Personally I would never expected that click on tab in panel (or even icon in action bar) would perform any actions: click on Run/Debug doesn't launch default debugger, Click on Remote Explorer doesn't suddenly start recently used session, Click on extensions - doesn't trigger search for selection or current file type, Click on terminal lease just shows latest state and nothing new etc.

@IllusionMH I believe clicking on the viewlet's icon should have the same effect as triggering the keybinding that opens the viewlet. Right now that keybinding both opens the viewlet and triggers the search. Maybe it'd be better to have a seperate keybinding for "Open search viewlet" vs. "run search"?

In my case I would expect (or prefer) "Open search (viewlet)" (new action, only shows viewlet, no default keybinding, triggered on click) and "Find in Files" that like "Open search viewlet & Run search" (shows viewlet, populates search with selection if available, runs search).

_UPD. That's because triggering search in files using shortcut or through menu is explicit action to perform search, however I see Search label in panel or icon in actions bar as tabs (like editor or browser tab) because in other cases they behave like this - show actual content (or cahed info) but do not perform actions on my behalf (document won't be formatted as soon as it opened)_

My 5垄 on other proposed options:

  1. Not a best option, but I have no problem with hitting Enter. However current behavior with instant search results on shortcut feels great. (I still looking if there is benefit to require Enter to add search entry vs pushing everything on debounce)

  2. This one looks tricky if previous statement still holds here

    clicking on the viewlet's icon should have the same effect as triggering the keybinding that opens the viewlet

Is it still disabled if user has new selection and hits Ctrl+Shift+F instead of just clicking on viewlet?
Would it be a) new search (user explicitly hit shortcut that performs search), b) search field seeded and focused, but "dirty" results stay until Enter, or c) only viewslet shown but no seeding and search?

Originally, clicking the search tab didn't copy text from the editor, but some mouse-oriented users specifically requested that, so we ended up at

the keybinding and the click should have the same behaviour

like Jackson says. But I agree that with searchOnType, this has become a little too aggressive and I've been annoyed by this too.

Selection-seeded queries don't trigger new searches

I think I prefer this solution. I don't see the issue with history though.

We special case "dirty" search results to disable searchOnType entirely

This seems too aggressive - someone will remove a search result then think that they can't search anymore.

Selection-seeded queries don't trigger new searches

I personally like a quick select => Cmd+Shift+F to have the results all good to go without needing to enter. Maybe keybinding to the viewlet runs search but clicking on it doesn't? It would be a difference between click and keyboard, but a pretty slight one.

Requiring enter to run selected text searches.

I believe its worth providing the user to turn it as per his need using a toggle option in the setting, rather than to get rid of this feature completely.

I think this could get a bit more clever:

  • still run the search automatically as before if search view is empty
  • also maybe you could detect if I removed results and run the search if I left the results untouched?

@bpasero Good idea, tracking in #91901.

@JacksonKearl since there are plans for improvements in this area - any chances to get option not to trigger search on click on tab but always on keyboard shortcut? Or this one won't be considered/discussed at all?

If it doesn't fit #91901 - I'll create new issue with details.

I think that's in scope for #91901

Was this page helpful?
0 / 5 - 0 ratings