Entering text in find widget should not clear the selection

[frostius]

• VSCode Version:1.8.1
• OS Version:Win 10

Steps to Reproduce:

1. Select two or more lines of text
2. Edit|Replace
3. Type search value into "find" input box
4. Weep as your selection is cleared
5. Explain to boss why you miss deadline because editor hates you

[egamma]

@mfrost66

Is the intent to preserve the selection so that find/replace is scoped to the current selection? Then you can do so and preserve the selection using the 'Find in Selection' setting.

[frostius]

When I enter a value in the "find" input box, it clears my current selection. Are you suggesting this is by design?

[egamma]

@mfrost66 the find widget has received lots of input and I cannot reconstruct the history. All I wanted to point out, is that the scenario to replace inside a selection is supported.

Changing the title and assigning to @alexandrudima for further comment.

[alexdima]

@mfrost66
I'm not sure what the desire is here. The find widget is incremental by design, i.e. results are selected as the search string is typed. This is consistent with Visual Studio, where we borrowed the find widget UX from. Would you like for the find widget to not search as you type, i.e. only when you press Enter or something?

[frostius]

@alexandrudima
I believe a more ideal implemention would be to preview the search/replace before execution, but not to modified the actual selection. There should be a distiction between search match(es) and the user selection(s). If a selection has been made, the replace should be limited to the selection.
Specifically:

• If a selection is active when search or replace widget is launch, default to "within selection"
• highlight the search match (and/or replace results) but do not override the user selection(s)

I believe this to be standard behavior in mainstream editors. See MS excel, MS word, intellij, visual studio. Imagine if excel ignored (or modifed) your column selection when you did a search/replace. See intelli as an example of an editor that previews the match but honors the selection. Regarding visual studio, I haven't used it in several years but as of 2014, it definitely did not override or ignore my selection.

Snapshot of webstorm search/replace in selection, note the highlight of the search match

[mbward]

@alexandrudima It looks like the Find field is only set when starting Find/Replace if the current selection does not contain a space.

How about only modifying the selection after the user clears the Find field then starts typing if the current Find is what set the selection?

Or something else, but the ideal is definitely that it should not clear the selection in the case described here.

[felixhao28]

I finally figured out how to use "find in selection", here are the steps for anyone googled here:

1. Use Ctrl+F (or whatever binds to search) to bring out the search popup.
2. Type what you would like to search in the search popup. This will by default search the full document.
3. Use Esc to close the search popup.
4. Select the selection where you want to search.
5. Use Ctrl+F to bring out the search popup again.
6. Click the "Find in selection" button in the search popup.

[myfonj]

Nice to have workaround for basic use case 👍, but beware that even this currently suffers several bugs:

• ✗ "Find in selection" toggle silently expands search and replace range of multi line selection to entire lines, so replacement can occur even outside the original selection. (Find in Selection expands to whole line #80008)
  

• ✗ Multiple (discrete) selection ranges simply do not work: "Find in selection" toggle simply discards secondary (non-primary) selections.
  

And to reiterate on this issue and unresolved issues merged here:

• ✗ Original selection is still lost after search field value change ("input")(this issue, and dupes like Search and Replace keep losing the selection #39190), with no mean to restore it again (Restore original selection if no matching result is found when closing the Find Widget #26927). (Primary cursor is technically selection as well, but in this case restoring its original position is at least possible via the "Go Back" command.)

• ✗ what relates to fact, that creating and cancelling selection in general is not treated as undoable action with undo history entry. It makes sense in most cases, especially when it prevents erasing redo history, but in other cases is a nuisance.

• ↑ solved by cursorUndo

---

Overall, I think that it is a mistake to (ab)use selection as "search results highlight". FMPoV selection should be "sacred" and nothing but selection-related actions invoked by user should alter its presence and shape. Search results should be something different, and only explicit search-related commands like "Select all matches" or "Select next match" should amend the real selection.

[jkyeung]

From @frostius:

I believe a more ideal implemention would be to preview the search/replace before execution, but not to modified the actual selection. There should be a distiction between search match(es) and the user selection(s).

From @myfonj:

Overall, I think that it is a mistake to (ab)use selection as "search results highlight". FMPoV selection should be "sacred" and nothing but selection-related actions invoked by user should alter its presence and shape. Search results should be something different, and only explicit search-related commands like "Select all matches" or "Select next match" should amend the real selection.

I made a similar comment elsewhere before finding out that this issue existed.

[mario-d-s]

TL;DR - set editor.autoFindInSelection to true in your settings. Upcoming version will support multiline value to only do so when the selection spans more than one line.

[myfonj]

🎉 cursorUndo command (#82007) newly implemented in v1.40 restores selections, so it is really viable workaround for our issues.

[jkyeung]

TL;DR - set editor.autoFindInSelection to true in your settings. Upcoming version will support multiline value to only do so when the selection spans more than one line.

@mario-d-s - I used to have it set to true, but it really didn't matter, because no matter the setting, the problem is that the fundamental functionality (preserving the selection until I actively change it) is broken no matter what. And it is apparently broken by design. The new version (1.40) does nothing to help in this regard.

@myfonj - Well, it is certainly nice to have cursorUndo, but to me that is not much help. It means Find/Replace is still as broken as ever, but then if I can remember to press some keys after it screws things up, I can sort of get back to where I wanted. This is not a good workflow. Ruining the selection is jarring and mentally disrupting and having to manually fix it, even if it's just one keystroke, breaks the flow. It is actually much smoother if I just remember to never, ever, ever have a selection active when I open Find/Replace. (In most cases, if I'm just matching literal characters (i.e. no regex) and I only want the matches in a localized region, I will use the multicursor feature instead of Find/Replace.)

[mario-d-s]

@jkyeung you do have a point, haven't looked at it that way yet. For some reason I'm not struggling that much with it when I change that setting. It's not ideal for sure so I hope the Code team will indeed fix this. It is quite set apart from the rest of the product in terms of quality.

[evangrayk]

Another consequence of auto-selecting when doing a find is that a search with a partial but incorrect result (search for "hey" in a file that happens to have "hello") leaves a wrong partial result selected and therefore highlighted. This makes it seem like "he" in "hello" was a match for "hey".

Exact Repro:

• Have a file with content "Hello"
• Open "find"
• Type h e. The "Hello" in the document gets partially highlighted & selected as you type. This is fine.
• If you then type y, the find no longer has any matches so says No Results.
• The He from "Hello" is still selected. This makes it visually highlighted, making you think at first glance that it was a match.

For more complex searches, this is very misleading. It would be nice if there was at least setting to not auto-select the find text.

[dwelle]

@evangrayk related #60977

[jgehrcke]

Sorry for writing a comment hat is not productive. But I'd like to share that "search and replace in a selection" is an incredible source of frustration for me on a daily basis in VS Code. This current issue here seems to be one of the problems that create pain for me. I come from Sublime Text 3 where search and replace in a selection simply worked intuitively for me. Maybe it can serve as an inspiration. I don't know. I get that we also cannot break the workflow of people who got used to the current behavior.

It's completely anecdotal, but I felt the need to vent about this here: https://gehrcke.de/2020/04/vs-code-i-cannot-quite-figure-out-how-to-search-and-replace-in-a-selection/.

I want to say THANK YOU to all those users creating GIFs and repros for exactly these WTF moments that probably many people around the world experience. CC @myfonj

[myfonj]

Sorry for minor OT, but somewhat related issue #80008 mentioned above is now asking for "👍" to be included in backlog; I think it might interest some commenters around here.

---

@jgehrcke thanks for appreciation, highly appreciated :]

[rebornix]

To mitigate the problem described in this original issue, we have already added editor.find.cursorMoveOnType to allow you postpone the selection change to pressing Enter.