search in files focus resets when line changed

[Spongman]

• VSCode Version: Code 1.9.1 (f9d0c68, 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.

[OliverJAsh]

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

The behaviour I'm seeing is not what was described as the expected behaviour in this issue. The behaviour I'm now seeing after following the steps: F4 progresses to the new 3rd search result (which was previously the 4th result).

[roblourens]

I see... now the list preserves the selected index in the list, but the result for F4 will be effectively skipping an item

We still need an F4 specific fix here. If you expect F4 to move focus to the next item after the removed one, and shift+F4 to move to the previous item before the removed one, there is nowhere we can put list focus that will satisfy this. So F4 needs to check whether the currently focused row index is now a different item that has not yet been revealed in the editor. Not what that actually looks like in code.

[russelldavis]

IntelliJ addresses this by never removing any items from the list. If a line is edited and no longer matches, the item remains in the list, but its text changes to "INVALID" (and the color changes to red). Seems like a nice, easy way to fix this.

[Spongman]

Visual Studio (since VC++ 2.0, not vscode) handled this by placing temporary, invisible bookmarks in the open file at the matching lines and referred to those bookmarks in the search results. If the open file was edited then the bookmarks would move, but the search results would defer to the correct location.

[andreamah]

Actually, I believe this is already fixed in the latest version.

2023-12-04.16-45-10.mp4

[rcdailey]

@andreamah Not quite, I think. In your video, after editing the search result, focus moved to the next search result but without changing the opened file (which is understandable since you're actively editing it). So when you jump to the next result, you're actually skipping one result I think.

[andreamah]

I was testing for the original issue, oops. Thanks for pointing that out.

[Daijobou]

Still not working for:
Version: 1.86.0 (user setup)
Commit: 0504748
Date: 2024-01-31T10:28:19.990Z
Electron: 27.2.3
ElectronBuildId: 26495564
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Windows_NT x64 10.0.22631

After edit selected line, without change search results, highlight is gone. Searched for ",abc" and changed it to ",123,abc".

[ghyman-oreilly]

Agreed, it looks like this issue may have been reintroduced with a recent update:

Version: 1.86.2 (Universal)
Commit: 903b1e9
Date: 2024-02-13T19:42:13.651Z
Electron: 27.2.3
ElectronBuildId: 26908389
Chromium: 118.0.5993.159
Node.js: 18.17.1
V8: 11.8.172.18-electron.0
OS: Darwin x64 23.2.0

[jaredplowman]

I can confirm this issue is back and driving me insane. You'll see in the following video that when I change Id -> Guid the search resets to the first item in the list.

[Daijobou]

Can this please be corrected, it is so tedious to work through search lists when the marker in the file list keeps disappearing.

[break11]

In version 1.94.0 the bug is still there. The search window is now completely broken. You can't search for something and press F4 to cycle through the search results. After editing in any result file the search results window is completely refreshed.

[break11]

Is it possible to simply add the setting "update the search list after editing files included in the result"? In my experience, it is not important to me that the search result after editing a file changes the line correctly on the fly. It is much more important to save the current edited element when switching to F4. If I need to, I can call the search list update manually - this is not a problem.

[HFriberg]

Here is a workaround until the bug is fixed:

1. Use ctrl-shift-f to get a list of matching files.
2. Use ctrl-f (with the same query), and press F3 to iterate over matches within a file (works as expected with respect to editing).
3. When you are done with a file, use the dismiss feature of the ctrl-shift-f menu. This one mouse click sends you to the next matching file where F3 works immediately.

Until the bug is resolved, this workaround gets the job done with only one mouse click per file, and one F3 per match.

[joeytwiddle]

Thanks for the tip @HFriberg. For anyone who wants to remap that, the command is search.action.remove. I couldn't find it in Command Palette. It currenty looks like:

{
  "key": "cmd+backspace",
  "command": "search.action.remove",
  "when": "fileMatchOrMatchFocus && searchViewletVisible"
}

Not an ideal solution, but better than sticking with the current behaviour.

By the way, this search.action.remove command sometimes ends up focused on the search results, sometimes in the editor, so you may need to hit Enter to get from the search results to the editor.