Vscode: search in files focus resets when line changed

[Spongman]

• VSCode Version: Code 1.9.1 (f9d0c687ff2ea7aabd85fb9a43129117c0ecf519, 2017-02-08T23:44:55.542Z)
• OS Version: Linux x64 4.4.0-62-generic
• Extensions:

|Extension|Author|Version|
|---|---|---|
|glslx-vscode|evanw|0.0.8|
|cpptools|ms-vscode|0.10.1|
|csharp|ms-vscode|1.7.0|
|mono-debug|ms-vscode|0.13.0|
|debugger-for-chrome|msjsdiag|2.5.3|
|arduino-vscode|steveyin|0.2.0|

---

Steps to Reproduce:

1. ctrl-shift-f search for a string that appears at least 3 times
2. hit F4 a TWO times to go to the 2nd result.
   
   
   
   • notice how in the search window the focused result is hilighted
   
   
3. now, edit the file (that contains the 2nd search result) so the line in that file no longer matches the search criteria.
   
   
   
   • notice how the 2nd search result disappears from the search results pane, and NO results are hilighted.
   
   
4. hit F4 again.
   
   
   
   • BUG: the first search result is hilighted.
   
   

expected: F4 should progress to the new 2nd search result (which was previously the 3rd result).

this bug breaks the process of using F4 to skip through results selectively editing, since every time you make an edit you have to start back at the beginning of the result. for hundreds of results, and many to skip repeatedly, this is extremely annoying.

[Spongman]

there's a race condition. if you hit F4 _immediately_ after the edit is made, then _sometimes_ it does the right thing. unless the edit alters the line length and there are multiple results on the same line, in which case the wrong part of the line is selected.

[Spongman]

it even breaks if you insert a blank line above the search result.

eg:

• search
• f4
• home
• enter
• f4

takes you 1st search result twice

i cannot emphasize enough how annoying this bug is when searching through files making various edits. i just ran into this again today - I had to switch to a different editor just to do this seemingly simple task.

[roblourens]

@bpasero, I want to preserve the focused element across a refresh of the tree, but this isn't really possible because search results don't have an identity across a change in the editor.

So what I want to do to make this a little better is to record that the, say, 25th match in file X is focused. Then refresh the tree. Then focus the 25th element in file X. We don't have a fast way to determine this from outside the tree, so I would probably implement this in the tree itself (with a option to selectively enable it) to restore the focused item by index after a refresh.

Does that make sense, or any other ideas? I thought it would be easier.

[bpasero]

@roblourens please consult with @joaomoreno , but if your tree items have no identity across a refresh I think it will be hard to preserve the selected element. Is it not possible to give the items the same identity?

[roblourens]

Sorry I can't keep track of who knows what. After an edit, the selected result will be at a different location, so unless you know what the edit did, you can't know that the selected match at line 5 column 7 is now at line 8 column 2.

[roblourens]

Similar case - after deleting a file in the explorer, the next file should be selected. Currently the selection jumps up to the folder that file was in.

[ramya-rao-a]

@roblourens Moving to March since you are not here ...

[yevhen-m]

What's the status here? This bug makes a very important workflow ("next-edit-next..") unusable.

[rlundy]

So given that this keeps getting reported and then closed as a duplicate, it seems like a lot of people would really like for this to be fixed. I'm certainly one of them.

Visual Studio handles this just fine.

Is there a reason Visual Studio Code can't?

[rbellamy]

The purpose of a search is often to make changes manually - this bug makes F4 unusable for anything but the most naive use.

[grandich]

VS Code is great, but I miss Notepad++ in this one. Seems difficult to resolve.

[Daijobou]

The error is really very annoying. I'm searching in a system that has hundreds of folders and all files in these folders have the same file name. As soon as you change something in a file, the marking of the file disappears from the search file list. This makes you crazy. You can hardly see the markings anyway.

One way to mitigate the problem would be to give the file a prominent icon or marker in the search list (NOT THE CODE LINE).
This way you would at least still see in which file you are and which file you have to view and edit next.