Works fine for me, I don't understand the problem. Can you be more specific or include a screenshot?

I'm having a similar issue. I've documented the problem in this Stack Overflow post. Very similar issue with the find/replace tool.

Still works fine for me. Can you try in Insiders? A gif/video would be great.

Here's a video: https://1drv.ms/v/s!AuxdNgJmWJNgl9gePfXS47vKv-pVWw. I haven't tried Insiders, but I'm running 1.12.2 (latest last I checked) on Ubuntu.

Ah I see. We used to enable find in selection automatically when opening the find widget with a selection, but it was too easy to trigger accidentally and produced a lot of complaints. You probably want to set "editor.find.autoFindInSelection": true which will make it work the way you expect.

What's happening is that you make a selection, open the find widget, then do a search for ., not in the selection. When you do a search, it selects each result. So the first result after the cursor is selected, and when you go press the find in selection button, it doesn't have the original selection anymore.

Hope that helps.

Works for me! I'll update the SO answer, Hopefully we can get the word out of the "editor.find.autoFindInSelection": true option.

I've added "editor.find.autoFindInSelection": true to settings.json, but I'm getting an "Unknown configuration setting" warning.

@jmounce are you using Stable? We didn't release 1.13 yet (it's coming this week) so right now you can play with this feature in Insider.

Ah I didn't realize that was a brand new option in 1.13, apologies.

I've tried with editor.find.autoFindInSelection = true, I still find it pretty janky. Find/selection still doesn't work as I would expect it to.

I confirm this feature implementation doesn't currently work as expected and is very buggy and inconsistent. I'm surprised there are not more complains and feedback about it as if nobody encountered this issue in their workflow.

Steps to reproduce (bug 1)

The bug occurs when you try to select one and only one line.

1. In settings.json → "editor.find.autoFindInSelection": true
2. Sample text

replace the `\` by a space in line 3 only with select it and use ctrl+H
bla\bla\bla
bla\bla\bla
bla\bla\bla

3. Select line 3 using mouse left click on the gutter (or triple click on line). By doing that, notice that line 3 is selected but the caret jump to start of the line 4 (maybe a hint for the issue).
4. Press CTRL+H and check out that find in selection feature is ON. It is !
   • first bug: you can notice that the editor.findRangeHighlightBackground color is not triggered
   • instead the editor.inactiveSelectionBackground color is triggered showing that line 3 is still selected but not affected by the auto find in selection feature that is ON yet.
5. If the search field is empty or with an unwanted query, then as soon as you edit the search field with \
   • the line 3 is unselected
   • the line 4 get the editor.rangeHighlightBackground color
   • the 6th matched by 7 \ on line 4 is selected triggering the editor.findMatchBackground color
   • all the \ matched in the file trigger the editor.findMatchHighlightBackground color
6. At this point the find in selection failed and you can not go further else all the \ in the file will be replaced and this is not what you wanted.
7. Keep the search widget active and disable the find in selection
8. Reselect the line 3 with the mouse in gutter again
9. Enable the find in selection
   • It sends you back to step 4: the editor.inactiveSelectionBackground color is triggered showing that line 3 is still selected.

Good luck to get out of this loop trying to do a simple thing.

Workaround

If "editor.find.autoFindInSelection": true

1. CTRL+H to call the search/replace widget first
2. Disable the find in selection feature as soon as you are allowed to
3. Important: You have to select the line 3 with mouse or keyboard being ensured the caret will end in first or last column of the line and NOT in the first column of line 4 as it is if you use the gutter selection method.
4. Enable the find in selection feature
5. 🎉 hooray ! the editor.findRangeHighlightBackground color is triggered on line 3 and only the \ in that line are matched.

BUGS 2

1. Again in settings.json → "editor.find.autoFindInSelection": true
2. Same sample text as above
3. Select line 2 and 3 using mouse left click on the gutter.
4. Press CTRL+H
5. The focus is on the replace field. Let's say you are happy with the query in the search field and only want to edit the replace field before running the replace command:
   • same bug: you can notice that the editor.findRangeHighlightBackground color is not triggered on the selected lines
   • instead the editor.inactiveSelectionBackground color is triggered showing that line 3 and 4 are still selected but not affected by the auto find in selection feature that is ON yet.
   • all the \ matched in the file trigger the editor.findMatchHighlightBackground color

Results

You can not directly use the replace field to only run the replace command on the selected lines.

Workaround 2

Just put the focus on the search field then the selected lines will trigger the editor.findRangeHighlightBackground color and only the \ in the selection are matched and can be replaced.

Conclusion

"editor.find.autoFindInSelection": true will enable the button in the search widget but will never work as expected.

This find in selection feature will play with your nerve when you only want to do what is expected:

1. Select one line or more or columns with any possible methods
2. Call the search or replace widget with "editor.find.autoFindInSelection": true
3. See that the find/replace function really concern the selected text
4. Be happy and start to work

For now, you'd better set "editor.find.autoFindInSelection": false then manually enable the find in selection feature in the widget ALT+L.

Bonus Bug 3

The ALT+L key binding won't work if only one line is selected with the gutter method and when enabled with the button, the find in selection feature won't prevent the bug 1 to occur but it is a workaround for the other case when you:

• select more than one line with gutter method or with SHIFT+↑ or SHIFT+↓
• select with mouse drag or keyboard specific columns

I would say those are severe bugs since it is a basic feature that every user has to use in its workflow from time to time.

Thanks for the detailed writeup :)

With autoFindInSelection enabled, if your selection is within a single line, then it will still search outside the selection. If I toggle the 'find in selection' button on and off, then it actually works as expected. That at least is definitely a bug 🐛 I'll leave the rest for @rebornix

Related or duplicate issues:
#14872
#22254
#26417

@roblourens How is Replace All supposed to work with find in selection? I don't so much care about what I have to do to enable "find in selection", but it makes no sense to me that even after it is enabled hitting "replace all" will replace every match in the file:

(please open gif in new tab if too tiny to see)

EDIT: Looks like Github has truncated the gif a few months after I first posted this comment, it looks like a 500 ms loop of nonsense now. The original full link to the gif is: https://rlgvlw.by3302.livefilestore.com/y4mXh_4dIcv6Huc1vuGJmJ7rfHzmz7sDC_mPeAwhssnYrKOvLiER7sP9iMkubRJOPUkCpyB5GuLgDmaVTX6GLPot6L1QI5edoJniMzJrjsEG08a-CX2S5mJ4RVAgo2nzRCGnvEp5aRb_VuW3oxrKrBwn6X8mchkBsa64p3QLQMLEuzD-pjWiwaFloIHV-3vjufVhp9Z4Ffjl_UCkoZ4qg93eA/2017-06-15_01-15-30.gif?psid=1

I'm also having trouble with changing the selection blocks when using Find/Replace in Selection. It does not change the search region automatically after I've selected a different block of text. For example, if one has two blocks of code with an unrelated string in between, the experience is lacking.
The number of matches is updated only if the search field (but not the replace field) is focused or the selection button is toggled. This creates a lot of unxpected behavior, like the editor jumping to the first global match.
My current workflow in this scenario is to select the first block and do a replace, then select the second block, focus the search input field and only then does it update the match count and the selection highlight area.

One simple bug I see is:

"editor.find.autoFindInSelection": true does not work for Replace

The Find in Selection icon is highlighted but the highlight in the editor is not there and replace replaces all entries.

Workaround: Press Alt+L (once), or press Ctrl+F before pressing Ctrl+H

Under these conditions the find selection editor highlight IS respected and is kept after doing replace all.

The fact the the icon is highlighted in itself seems wrong, it should be tied 1:1 to the current find mode and getting out of sync should not be possible.

I confirm that find and replace in selection is inconsistent--whether autoFindInSelection is true or false. That is a red herring.

When you toggle in-selection mode in the S&R dialog, the target replacements might or might not be limited to the selection. In addition, the selected text becomes unselected most of the time.

What's weird to me is that it also happens in Atom. I got so fed up with it there that I downloaded Code today--only to find exactly the same behavior! Is that a clue to the cause?

@aztecrex - That may well be a clue. I have also seen hints that some or all of this behavior is modeled after Sublime Text. I think the idea is that the "Find and Replace in Selection" paradigm many of us are used to or expecting is somehow outdated and inferior.

Incidentally, I have been trying to evaluate both Atom and VS Code. Both are wonky (to my taste) in this regard, but at least in Atom, the dialog always includes Replace, so there isn't the issue of something working differently depending on whether you started with Ctrl+F or Ctrl+H. And the "within current selection" option is at least very obvious, and "sticky" from one invocation to the next.

The main problem is that F/R box doesn't update its find selection context until you focus on the find field. The moment you do that, find count updates and you can do the replacement. So the only way to make speedy multiple selection replacements is to focus the find field every time you want to make a replacement in the selected text.

Voila. It's a bug, that needs fixing, but this mitigates it rather nicely.

@roblourens , @AdamBJ
Big thank you for "editor.find.autoFindInSelection": true. It saved me from so much frustration.

Let's try to fix issues mentioned above one by one ;)

1. find in selection doesn't work with single line selection Find/Replace using selection is very messed up #27083 (comment)

2 #27083 (comment)

Alt + L

3 #27083 (comment) #27083 (comment)

Above changes will be shipped in tomorrow's Insiders. Can anyone help me understand if I miss anything/bug ?

I'm coming from Geany 1.32 on Ubuntu and I'm loving VSCode so far but this is functionality feels really clunky compared to that of Notepad++, Geany, Atom and others. It's good to see I'm not the only one frustrated with this.

Typically I'd either like to replace all occurrences of text in the open file or I'd like to replace all in the selection.

I've managed to get the first case working with CTRL + h, type old text, TAB, type new text, CTRL + ALT + ENTER.

Replacing in selection is a little more involved with Select Lines, CTRL + h, ALT + l (to replace in selection) type old text, TAB, type new text, CTRL + ALT + ENTER

A few irritations with this:

1. The selection is forgotten if you ALT + l toggle out of the replace in selection option and back in again.
2. The shortcuts are unintuitive. Why not just have a separate execution shortcut like CTRL + ENTER and just don't mess with the user selection at all? A "Replace all in Session" to replace in all open documents would be great too. Maybe it's there already, but I'm missing it?
3. The find-replace dialog is out of the main area of focus and the controls are tiny and hold little weight:
   
   Here is the Geany Find-Replace control for contrast (done right in my opinion):
   
4. The first find field should always be the default focus and it should be selected by default IMO for easy replacement. CTRL + TAB'ing every time I want to find something else is yet another step for each new find replace case.

@chambead thanks for your feedback, really insightful.

The selection is forgotten if you ALT + l toggle out of the replace in selection option and back in again.

let's track this issue in #50567. Once the Find In Selection is toggled off, we will do another search in the whole document and move the selection to the nearest match so the next Find In Selection toggle can not bring back the search range. That's what we need to investigate into.

A "Replace all in Session" to replace in all open documents would be great too

Feel free to create a feature request for Search Viewlet, Find Widget is focusing on single file.

The find-replace dialog is out of the main area of focus and the controls are tiny and hold little

We can resize the find widget horizontally but not vertically.

The first find field should always be the default focus and it should be selected by default IMO for easy replacement

If we set editor.find.seedSearchStringFromSelection to false, then each time when we invoke the replace box, the find input is focused.

Just found this issue and tested the insiders build and I found two main problems:

• If you have seed from selection set to true and you try to find in selection with a single line it still seeds from selection (I think this should not happen at all when using find/replace in selection).
• When you find in some selection (single or multi line), then select some other single line pressing ctrl+f again, it doesn't change the selection (if you select multiple lines it does, and works as I'd expect). You have to toggle the selection mode on/off to change it.

Also, don't know if this has been mentioned, but it's the thing that bugs me the most:

• When you close the find dialog it resets to a regular find (not in selection).

The only reason it should change is if I closed the dialog then tried to find again with no selection, and even then, I'm not sure if it's better to just use the previous selection or the active line in those cases.

Another way to tackle it might be to allow starting the find dialog in different modes? For example: ctrl+f = regular, ctrl+alt+f = start with selection? I think I'm going to make myself some macros for this. I looked to see if this existed btw, and found a kind of confusing "Find with Selection" shortcut. I feel like maybe it should be called "Seed Find from Selection", though that's minor complaint. Btw, does anything like this exist to seed the replace text? Would be really useful. I could make my workflow:

1. Select lines - > Ctrl + F
2. Select seed text -> Seed Find
3. Select replace text -> Seed Replace
4. Replace

even after minutes could not replace inside the selection.
verison 1.27.2

I think I have found another workaround. It seems to me that the find in selection works if I highlight my selection from the end to the beginning and leave the cursor before the selection. Otherwise, the selection jumps to whatever is next. I still think that this is wrong behavior, but I hope it might save some people some headache.

i have to add that lately, still with 1.27.2, i am able to replace inside selection without problems. not sure what makes the difference between back than and now. i assume my problem was related to the specific file and file format (typescript, jsx in the problematic case).

This is definitely so horrifically broken it's laughable. I've struggled and struggled to replace in selection and it's infuriating. I will try with the autoFindInSelection turned on and I hope that will at least help somewhat. It's really frustrating you can't select new selections while the find dialog is open and operate on those sections. It's one really glaring issue in an otherwise stellar product.

Considering that the issue is 2 years old I think it's better to open PR and fix everything rather than waiting for devs to react ...

One thing I'm seeing that I didn't see mentioned here is that when I CTRL+H to replace, with auto find in selection set to true, and then I hit TAB to move from the "Find" field to the "Replace" field, it instead auto completes text in the editor. As if the focus isn't truly in the "Find" field to begin with.

I have another problem with multi-cursor select. It replaces only in the "first" selection (The one where the original cursor is). Should I report a new issue?

https://drive.google.com/open?id=1FfTJ5pk09iU5V-8Xh1NzLeCMFxx_lH6B

I think the option autoFindInSelection should be changed to just findInSelection and allow three different values:

• always: always find in selection, even if a single word is selected, equivalent to the current autoFindInSelection:true option
• never: never find in selection, always use selected text to autofill the search box
• auto (default value): if one entire line or more lines are selected, use find in selection, otherwise use the selection to autofill the search box

i don't think there's a need for a different findInSelection option.

It never makes sense to 'find in selection' if the find input is initialized with the value of the selection. there's no need for an option to say 'always do something that never makes any sense', just don't do the broken thing.

visual studio proper has always done the right thing here, choosing 'current document' instead of 'selection' when doing a ctrl-f3.

i don't think there's a need for a different findInSelection option.

It never makes sense to 'find in selection' if the find input is initialized with the value of the selection. there's no need for an option to say 'always do something that never makes any sense', just don't do the broken thing.

If you are referring to my soution, I didn't propose any such option that does both things at the same time, as it wouldn't make sense, as you suggest.

I have included always just to reflect what I reckon is the current behavior when autoFindInSelection is set to true. I wanted to keep this behavior because people have asked, and obtained, this in past issues. Obviusly with this option the box should never be autofilled, perhaps I forgot to clarify that.

never also reflects current false (with the only addition to always autofill the box, which can help search faster, but is innocuous if you wanted to search anything else, since the box is focused and you can just start writing right away to replace the prefilled text).

auto is just what most people would expect from a smart editor, and what should be the default. This has been asked in different ways in many issues, some of which are referenced above.

Thanks all for your contribution to this topic and thanks @xates for your proposal, it makes perfect sense that for a lot of time you only want to auto find in selection when it's across multiple lines.

It used to be like what's being proposed above but I think years ago when we hear the complains about auto find in selection not working when searching in long lines, we relax it a little bit to support all cases. But it definitely break the experience for single line, especially when using with seedSearchStringFromSelection.

From next weeks' Insiders, editor.autoFindInSelection will have a new type of value multiline, to allow you only use selection as scope only when it's across multiple lines.

I appreciate all the work and attention that has gone into this, but I don't think I will ever be truly comfortable with Find/Replace in VS Code. The issue for me is that the "find in selection" button looks and feels like a toggle switch, not a trigger (or "fire button").

If you flip a toggle switch from one position to the other, and then back to the original position, it should be as though you had never flipped the switch at all. With this mental model, it is always a shock and a disappointment when flipping the switch irreversibly destroys my carefully crafted manual selection.