microsoft / vscode

Visual Studio Code
https://code.visualstudio.com
MIT License
162.42k stars 28.62k forks source link

Replacing a string with a new one that contains the search term does not exclude the result from the search panel #226516

Closed s-kai273 closed 1 day ago

s-kai273 commented 3 weeks ago

Type: Bug

  1. Open new text and type hogehoge
  2. Press ctrl + shift + H key to open search panel
  3. Type "geho" in search textbox(you can see the text as searched result)
  4. Type "gehoge" in replace textbox
  5. Press Replace button(not Replace All)

Then, the result is not excluded because the replaced string also contains the search term. But expected behavior is maybe excluding the result.

The reason I guess is,

  1. You cannot reduce searching result by pressing Replace button
  2. When pressing Replace All button, all results are excluded

VS Code version: Code 1.92.2 (fee1edb8d6d72a0ddff41e5f71a671c23ed924b9, 2024-08-14T17:29:30.058Z) OS version: Linux x64 5.15.0-118-generic Modes:

System Info |Item|Value| |---|---| |CPUs|Intel(R) Core(TM) i7-7600U CPU @ 2.80GHz (4 x 3593)| |GPU Status|2d_canvas: enabled
canvas_oop_rasterization: enabled_on
direct_rendering_display_compositor: disabled_off_ok
gpu_compositing: enabled
multiple_raster_threads: enabled_on
opengl: enabled_on
rasterization: enabled
raw_draw: disabled_off_ok
skia_graphite: disabled_off
video_decode: enabled
video_encode: disabled_software
vulkan: disabled_off
webgl: enabled
webgl2: enabled
webgpu: disabled_off
webnn: disabled_off| |Load (avg)|1, 1, 1| |Memory (System)|15.37GB (2.25GB free)| |Process Argv|--crash-reporter-id 2cb0a35c-66df-448a-9137-22b1f2728a9e| |Screen Reader|no| |VM|0%| |DESKTOP_SESSION|cinnamon| |XDG_CURRENT_DESKTOP|X-Cinnamon| |XDG_SESSION_DESKTOP|cinnamon| |XDG_SESSION_TYPE|x11|
Extensions (43) Extension|Author (truncated)|Version ---|---|--- project-manager|ale|12.8.0 arepl|alm|2.0.5 vscode-django|bat|1.15.0 gitignore|cod|0.9.0 python-snippets|cst|0.1.2 vscode-eslint|dba|3.0.10 vscode-dash|dee|2.4.0 python-extensions-pack|dem|1.0.3 git-extension-pack|don|0.1.3 githistory|don|0.6.20 python-environment-manager|don|1.2.4 python-extension-pack|don|1.7.0 gitlens|eam|15.3.1 prettier-vscode|esb|11.0.0 vscode-github-actions|git|0.26.3 vscode-test-explorer|hbe|2.21.1 python-resource-monitor|kai|0.2.3 vsc-python-indent|Kev|1.18.0 vscode-python-test-adapter|lit|0.8.2 git-graph|mhu|1.30.0 document|min|2.2.2 black-formatter|ms-|2024.2.0 debugpy|ms-|2024.10.0 python|ms-|2024.12.3 vscode-pylance|ms-|2024.8.1 cmake-tools|ms-|1.18.44 cpptools|ms-|1.21.6 cpptools-extension-pack|ms-|1.3.0 test-adapter-converter|ms-|0.1.9 autodocstring|njp|0.6.1 vscode-python-typehint|njq|1.5.1 indent-rainbow|ode|8.3.1 sourcery|sou|1.22.0 code-spell-checker|str|3.0.1 vscode-djaneiro|the|1.4.2 wolf|tra|0.4.3 cmake|twx|0.0.17 intellicode-api-usage-examples|Vis|0.2.8 vscodeintellicode|Vis|1.3.1 vim|vsc|1.27.3 jinja|who|0.0.8 livecode|xir|1.3.10 vscode-open-in-github|ziy|1.3.6 (1 theme extensions excluded)
A/B Experiments ``` vsliv368cf:30146710 vspor879:30202332 vspor708:30202333 vspor363:30204092 vscod805:30301674 binariesv615:30325510 vsaa593:30376534 py29gd2263:31024239 vscaat:30438848 c4g48928:30535728 azure-dev_surveyone:30548225 962ge761:30959799 pythongtdpath:30769146 welcomedialogc:30910334 pythonnoceb:30805159 asynctok:30898717 pythonregdiag2:30936856 pythonmypyd1:30879173 h48ei257:31000450 pythontbext0:30879054 accentitlementsc:30995553 dsvsc016:30899300 dsvsc017:30899301 dsvsc018:30899302 cppperfnew:31000557 dsvsc020:30976470 pythonait:31006305 dsvsc021:30996838 da93g388:31013173 pythoncenvpt:31062603 a69g1124:31058053 dvdeprecation:31068756 dwnewjupytercf:31046870 newcmakeconfigv2:31071590 impr_priority:31102340 nativerepl1:31104043 refactort:31108082 pythonrstrctxt:31112756 wkspc-onlycs-c:31111717 wkspc-ranged-t:31123313 ei213698:31121563 ```
andreamah commented 2 weeks ago

Hmm, that's an interesting take. I think that you could argue for both. However, keeping it in the results keeps the search accurate, and it stops us from needing to keep track of all of the 'replaced' matches. It also gets tricky when you start to think about how we can keep track of these 'replaced' matches upon file changes; since Search isn't aware of syntax, it would need to track all of the user changes in order to see where the 'replaced' matches went so that we can avoid them again.

s-kai273 commented 1 week ago

Thank you for your response. I understand your opinion, and I completely agree with it. However, if we adopt this approach, I believe it should also be applied to the "Replace All" function (which currently isn't the case).

At the moment, when we use "Replace All" under the same conditions, all results are removed from the panel, which seems inconsistent.

I find this behavior of excluding unmatched results a bit unnatural.

andreamah commented 1 week ago

I can see that being controlled by a setting. If you want, we can make this a feature request candidate to see whether a lot of people would want this. I see where you're coming from with this, but I wonder if people are used to seeing a clean search view when they 'replace all'.

vs-code-engineering[bot] commented 1 week ago

This feature request is now a candidate for our backlog. The community has 60 days to upvote the issue. If it receives 20 upvotes we will move it to our backlog. If not, we will close it. To learn more about how we handle feature requests, please see our documentation.

Happy Coding!

vs-code-engineering[bot] commented 1 day ago

This issue has been closed automatically because it needs more information and has not had recent activity. See also our issue reporting guidelines.

Happy Coding!