The behavior of ctrl+f was changed in June_2016

[mysticatea]

• VSCode: Version: 1.3.0
• OS Version: Windows 7

Steps to Reproduce:

1. Select text (multiline)
2. ctrl + f or ctrl + h

Previously, it enables find in selection by default.
But it disables find in selection by default since June_2016 update.

---

Could I revive the previous behavior?
I could not find the setting by searching in the default setting file by find, search or select.
My 2 cents, the new behavior is inconvenient for me.

[weinand]

Find in selection is now available under this button:

[alexdima]

With the support for multi-line search added in June, the auto-seeding of the search scope from the editor selection on find field focus was causing a lot of issues where the search scope was constantly seeded from multi-line search results.

I can look into adding an option to add the ability to get the old behaviour back.

[mysticatea]

Thank you very much.
I'm looking forward to 2016_July update.

For what it's worth:

• Visual Studio 2013 has similar behavior to the previous behavior of VSCode.
• Sublime Text has this option (auto_find_in_selection) and it has the support for multi-line search.

[alexdima]

👍 I'm thinking to differentiate between selections caused by a find result vs manual "hand-crafted" user selections. If the selection was caused by jumping to the next find match (even if it is multiline) it would not auto-set the search scope. If the selection was created explicitly, and then the focus goes into the find input, then the search scope gets auto-set.

[alexdima]

The fix is:

when the find field receives focus the search scope gets seeded (same as before) only if the editor selection is not the current find match (new condition, added to accommodate multiline find)

[mysticatea]

This issue seems to appear again in October 2016 (version 1.7).
May I reopen this issue or open new issue?

[alexdima]

@mysticatea This was independently of me changed by @roblourens in 79bc7a8 . Please bring up your points with the other project members that took this decision in #12109.