/claim

Thanks for claiming the issue! 👋

Here are some links for getting setup, contributing, and developing. We're always happy to answer questions in slack! If you become busy, feel free to /unclaim it.

🦊 Debugger team!

I read the whole code and ohh my gawdd....,
Current Searching Algorithm ( Both for In-File Search and Project Search ) :
Step 1: Get Input from SearchInput Component.
Step 2: Search query in sources.
Step 2 returns: Results which contains Array<Match>
Now, Match contains MatchIndex <---- Problem
It should be MatchIndexes , As Query is being searched line by line and instead of pushing a new MatchIndex to MatchIndexes, We are Creating a new Match which is quite inefficient.

We should Use MatchIndexes: Array<number> instead of MatchIndex: number> in a particular Match.

Now, Step 3 is worse (currently):
Step 3: Then From Search Results, In-File Search is rendering line by line by finding in whole array of Matches, Line by line.

Should I proceed with modifying the code?
@jasonLaster @darkwing

Hi @charanjit-singh, can you edit this issue's title to make it clearer what specific UX issue you're trying to improve? Maybe something like "[ProjectSearch] Collapse results when they occur on the same line of same file"?

Two things to keep in mind:

1. There have been a few issues with project search performance and memory usage. It might be a good idea to look up past issues (open and closed) and see if some of the code problems you're seeing were made on purpose to avoid perf issues. (Some of your code exploration seems to hint at performance problems and possible ways to solve them, which is great.)

2. Lines can be longer than the result display. For instance if you have a narrow Debugger viewport (DevTools docked to the right), the result display can be narrow too. If you have a 80 character line, with a match at column 4 and a match at column 70, it might be impossible to show both as a single result. And source files can have very long lines, especially when minified. You can get 50 matches in a single line, at columns 100, 500, 3087, 32499, 54002, etc.

Displaying each match as a single result works around that second issue. It seems to be what VS Code search does, too.

I got it. We can provide a toggle button to users to choose modes, either single line results or multiple results.

We can provide a toggle button to users to choose modes, either single line results or multiple results.

I would rather avoid creating new preferences. :/
Mainly because that's a lot of work to do right (UX & dev), and you still end up with 99% of users who just keep the default behavior anyway.

Can we come up with a robust default for the "collapsing" scenario?
Maybe a kind of condition, like "if a match is on the same line as the previous match and the columns are less than N characters apart, merge the two matches; otherwise, show as two different results"?

Some examples with a bunch of results on the same line.

Yeah!
What we can do is:

If search result on same line are close to each other, then show them on same line,
Otherwise After a certain length, Create New Line.

Should I start working on this?
Pull Request #8051 needs to be merged before I can start.