-- Sorry for the English, I used Google Translator --
If I put the cursor on the word (start, middle or end of word) and press ctrl + f
, that word is automatically placed in the search.
Is not that wrong?
The correct would be if I selected the word and then pressing ctrl + f
it should appear in the search field.
It's not really wrong. If you don't like it, we can make a setting for it.
Thank you @joaomoreno
@alexandrudima @joaomoreno I compared it to other editors (Atom and Sublime). If there is person they like, maybe an option to turn it on and off.
To expand on the reporters description, the current behavior makes it oddly difficult to "find again". For example I just searched a Javascript file for the start of arrow functions ) =>
, and removed the parenthesis from functions with a single parameter. After each edit I had to make sure I moved the editor cursor to empty whitespace before pressing Ctrl-F again, otherwise I had to retype my search value.
I'm having the same issue that @coreyfarrell explained. Here is my usual/desired workflow:
If anyone knows a way to work around this or just stop the editor from changing the Find that would be great.
Continued from #17562 as requested. That said, this is really about usablity of replace
If a multi-line selection is made and replace
is invoked (ctrl-h):
find in selection
Reasons:
@mfrost66 I wish. At one point ctrl+f behaved something like that, but it confused OSX users.
-- Sorry for the English, I used Google Translator --
@rebornix I found these new functions:
"editor.find.autoFindInSelection" and "editor.find.seedSearchStringFromSelection":
I did not understand their operation. Besides that, what I have reported is not happening.
My problem is:
1- Place your cursor over a word.
2- Press Ctrl + f.
3- The word goes to the field of research and I do not want to search it.
Now if I had selected the word and pressed Ctrl + f, then yes it should go to the search field.
@rebornix Can you check and answer me, please?
Can @rebornix or anyone check (@joaomoreno @alexandrudima ) and reopen this issue?
At least it is being open to there is the possibility of someone looking at it.
@Tekbr I see what you mean, you are actually asking for populating from selected range but you don't want to auto populate the word under cursor, right?
-- Sorry for the English, I used Google Translator --
@rebornix See this gif. This can not happen, in my opinion. Place in the search field the word where the cursor is stopped (beginning - middle and end of word). By pressing Ctrl + F or Ctrl + Shift + F or clicking on the magnifying glass (search) in the sidebar.
Now, if I had selected the word, fine, that's correct, like showing the gif below.
Note: Can you explain to me what new functions are? - if possible with a gif. Thank you.
@rebornix I found these new functions:
"editor.find.autoFindInSelection" and "editor.find.seedSearchStringFromSelection"
:
@rebornix Can you check and answer me, please?
editor.find.seedSearchStringFromSelection
is used to populate the search string by the word under cursor of selection when you search. It means if you put your cursor around a word, the word will be populated; if you select a few characters, these selected characters will be populated.
editor.find.autoFindInSelection
is about whether to toggle Find In Selection when you select a few characters in the editor and run search.
-- Sorry for the English, I used Google Translator --
@rebornix Which does not solve the problem of the question made in the first post. Can you please reopen the question? I showed and I mentioned in the above comment the problem.
My suggestion for dealing with this issue would be to extend seedSearchStringFromSelection
, e.g. to an enum of: "off", "cursor", "selection"
"off" = false
.
"cursor" would behave like the current true
, where either selection or the word under the cursor are used.
"selection" would only replace the search if the selection is non-empty.
(For total control and consistency it would have be an array of options, so that "cursor" would not imply "selection". Disabling it would then be the empty array.)
Personally, i usually search by selection or modifying the previous search, so either having my previous search be replaced by whatever is under the cursor or not having the option of searching by selection at all is not very helpful.
-- Sorry for the English, I used Google Translator --
A week went by, and no answer was given by @rebornix . Even though he had previously reported that the problem had not been corrected. It can not even reopen the case, even showing the problem's gif and what the problem is.
I know the same could be busy with other problems, but take 1 minute to be able to respond or less reopen the question he can not. I know you can claim, "Why do not you offer a PR?" If I had known I would have done it or at least helped. But I do not have conditions right now.
With a closed question it will not be possible for anyone to look at it. So if @rebornix can not solve the question, who can someone ( @joaomoreno @alexandrudima ) reopen for it? Because it is a resource request and said nothing because of not implementing the resource.
Thank you.
@Tekbr sorry for the late response, I was working on endgame and testing so didn't catch up with github notifications. Your suggestion of a enum value for seedSearchStringFromSelection
is an option for this issue.
-- Sorry for the English, I used Google Translator --
@rebornix Thanks for the answer.
The idea of being an emun type
was not mine, but @brunnerh . I think @brunnerh idea can solve (if Google Translator translated correctly. 🤔 ). What I really find annoying is: regardless of where the cursor is, by pressing Ctrl + F
or Ctrl + Shift + F
or clicking on the search (magnifying glass - sidebar)
fill in the field automatically for the search. The correct one for me is only when we select the word and press Ctrl + F
or Ctrl + Shift + F
or click on the search (magnifying glass - sidebar)
it fills the field.
I completely agree with Tekbr, this feature is a must.
Please include it asap.
Thanks in advance
Hello, are there any plans to work on this?
I believe using an enum as suggested earlier would help people that are getting confused by the "cursor position erases my current search" behavior.
I often do a manual search and replace inside a file (for example, if not all matches have to be replaced).
In Eclipse I used to select the text I want to search and pressed "ctrl+k", which jumped to the next match.
Then I replaced the match (if needed) using ctrl+v and continued my search with ctrl+k.
In vscode, however, every hit of ctrl+k (I am using Eclipse keybindings) replaces my search-string with the one under the cursor, hitting F3 has the same effect.
It would be cool, if this could be changed using a setting.
I also find this incredibly annoying. I typically want to retain the thing I am searching for, but this keeps replacing it. Being able to select between: off, cursor, selection, as suggested above, would be fantastic.
I love VS Code and never looked back from Atom, but this is one detail that Atom seems to have gotten right.
@Tekbr here's a how-to:
Preferences -> Settings -> User settings window
then add:
{
// ...
"editor.find.autoFindInSelection": false,
"editor.find.seedSearchStringFromSelection": false
}
Then CMD+P
and type: >Reload Window
Now the behavior should be disabled.
i'm totally with @brunnerh : https://github.com/Microsoft/vscode/issues/20768#issuecomment-311069610
now 18 months passed and no fix?
Agreed
Sent from my iPhone
On Dec 24, 2018, at 1:28 AM, yumeyao notifications@github.com wrote:
i'm totally with @brunnerh : #20768 (comment)
now 18 months passed and no fix?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or mute the thread.
Even after a year of use, this is by far the most frustrating thing about VS Code. I often use find --> edit --> find again functionality, and this makes it very hard to do. More often than not, I already press Cmd+F Enter before I realize that the search term has changed, thus losing my work location.
In my opinion, the "selection" option should be the default. The use cases are:
If you choose a word by mouse, it's trivial to double-click it and then search. If choosing by keyboard, you can press Cmd+D to select the word before searching.
Currently the only way to make the find --> edit --> refind flow work is to disable editor.find.seedSearchStringFromSelection
. In that case, if you want to search for a word, you need to choose, Cmd+C, Cmd+F, Cmd+V, which also overwrites the current clipboard (nasty if you want to paste something at the next location).
Still no solution? This is a very annoying feature. This issue has been raised for 2 years. Means it has annoyed thousands of users for 2 years. Gosh.
A workaround here is to use up arrow
in find input box.
Say you choose foo
and use ctrl f
to find, then you want to change that search string to fob
, you press ctrl f
again, but it changes to a string your cursor is positioning at, which we don't like. Then you could press up arrow
to track search string history. In this case, we press up arrow
once and we'll get string foo
back again.
This is a super annoying bug, and it's going to drive many users away from VS Code. If you think about it like this:
ctrl f
againAny time that a program eliminates manual work the end user did and forces them to do it again is a huge problem. This is exacerbating by nobody expecting this "cursor" behavior by default - no other editor works that way by default. Keep the highlighting for sure - that's a deliberate action on the user's part, so the behavior is expected. But the default behavior right now is a bug, and it's one that thousands of developers are encountering multiple times every day.
How can we escalate this? Is it possible to place a bounty on it? IMO "backlog" is an awful milestone for something this annoying and this impactful to the core user experience.
I've opened a pull request to completely replace the current behavior: #80477
I don't think having multiple configuration options is worth the technical debt since the current behavior is bad UX and inconsistent with practically all other software, anyway.
Can someone with merge permission please have a look? It's a really small change.
Most helpful comment
I'm having the same issue that @coreyfarrell explained. Here is my usual/desired workflow:
If anyone knows a way to work around this or just stop the editor from changing the Find that would be great.