Repository navigation
File search incorrectly reports shown matches (shown file count vs shown match count) #3720
Description
Let's make sure issue is not already fixed in latest builds first.
- I looked at the source code of the master branch (FileSearchPage.java) and the code seams to be identical to the code in my Eclipse 4.35 installation.
Steps to reproduce
Create a text file with the following 3 lines:
ABC
ABCBC
ABCDCDC
Then do a file search on the file and search for "A". The label of the search view says "3 matches in ..." OK
Then repeat the search and search for "B". The label of the search view says "4 matches in ... (showing 3 of 4 matches)" which is NOT OK because all matches are shown.
If you search for "C" the label will be "6 matches in ... (showing 3 of 6 matches)" which is also NOT OK.
Since all matches are shown in the search view the view should not report not shown matches.
Locking at the source code of the label generation in FileSearchPage.getLabel() the problem seams to be an incorrect comparison of lines (leaves in the tree) and matches in the first if branch that generates this label extension.
Tested under this environment:
- OS & version: Windows 11
- Eclipse IDE/Platform version (as shown in Help > About): 4.35
Community
- I understand reporting an issue to this OSS project does not mandate anyone to fix it. Other contributors may consider the issue, or not, at their own convenience. The most efficient way to get it fixed is that I fix it myself and contribute it back as a good quality patch to the project.
Activity
iloveeclipse commentedon Feb 2, 2026
Still on master:
Are you sure it is a recent regression? The code in question was last touched 2 years ago, see 0474b01
[-]File search incorrectly reports not shown matches[/-][+]File search incorrectly reports shown matches (shown file count vs shown match count)[/+]bremk42-sys commentedon Feb 2, 2026
Wow, quick response. I will check that in the latest version I get. But if this screenshot is from the master, it shows the problem. "showing 3 of 4 matches" should not be added to the label because all 4 matches are shown.
iloveeclipse commentedon Feb 2, 2026
It is, otherwise I wouldn't write that.
bremk42-sys commentedon Feb 2, 2026
Okay, thanks. Then I am sure that this should be fixed.
iloveeclipse commentedon Feb 2, 2026
Contributions are welcome. See https://github.com/eclipse-platform/eclipse.platform.ui?tab=contributing-ov-file
fedejeanne commentedon Feb 4, 2026
Nope...
bremk42-sys commentedon Feb 4, 2026
Nope? So please help me to understand the label extension "showing 3 of 4 matches".
Since no match is filtered out because of a filter or a limit, it should say "showing 4 of 4 matches" or just nothing.
For me it looks like the current meaning is somewhat like "showing 3 lines with 4 matches" but this information is just confusing.
tomaswolf commentedon Feb 4, 2026
"Nope" meant "it's not a regression; it was like that already in Eclipse 2024-12 (and possibly older versions)".
Evidently the label mixes up number of lines vs. number of matches. Whenever a line has multiple matches, the label will be wrong.
fedejeanne commentedon Feb 5, 2026
@bremk42-sys I meant it's not recent.
But it's definitely a bug, it needs to be fixed :-)
deepika-u commentedon Jul 13, 2026
I've done a bit of exploration on the sample shared and wanted to share my observations before putting up a PR.
Case 1 - single occurrence per line: i see the text as
'BCD' - 3 matches in workspace (*.txt)as shown in below screenshot, 2nd part doesnt show up atall.Case 2 -> when there are multiple occurrences in the same line, i see the text as
'BC' - 9 matches in workspace (*.txt) (showing 6 of 9 matches)as shown in the below screenshot ==> 9-matchCount & 6-lineCountSo going by that meaning now, i have 5 options to update the text as such to make it meaningful and complete for user and no logical change. Below are few options I can think of(original text being -
'BC' - 9 matches in workspace (*.txt) (showing 6 of 9 matches))option 1 as
'BC' - 9 matches in workspace (*.txt) (showing 6 lines of 9 matches)option 2 as
'BC' - 9 matches in workspace (*.txt) (9 matches in 6 lines)option 3 as
'BC' - 9 matches in workspace (*.txt) (in 6 lines)option 4 as
'BC' - 9 matches in workspace (*.txt) (found on 6 lines)option 5 as
'BC' - 9 matches in workspace (*.txt)- here the 2nd part(in number of lines) is being removed totally because anyways we are showing all the lines below.Or does anyone else has any other opinion on this? My vote goes for option 3 or 4 so that someone would read it like
9 matches found on 6 lineswhen read at once so that match count is not repeated anymore.iloveeclipse commentedon Jul 13, 2026
Not sure why the information about lines is important in search status line?
Is this useful somehow, for which use case?
The most important part is to give a hint if one or more matches are NOT shown for some reason.
Assuming there is no use case to show number of lines with matches:
deepika-u commentedon Jul 14, 2026
I get your intent, let me check on it indetail once again and get back to you. Thanks for your opinion.
deepika-u commentedon Aug 11, 2026
Thanks for the feedback - I largely agree with your framing, especially that the main priority is signaling when matches are genuinely missing, not the line count itself.
That said, I'd like to keep the line-count message (option 4), for a couple of reasons:
On your main point - matches not being shown - I've addressed that directly: I added a check that recounts the actual matches present in the visible tree and compares it against the true total. If the visible count is less than the total, that's a genuine truncation, and the user is informed via the existing (showing X of Y matches) message so they know to investigate further (e.g. raise the display limit). This check is independent of the line-count message, so both concerns are now handled separately and correctly:
Opened the PR #4233 with both pieces in place - happy to iterate further if the line-count message still doesn't sit well.
iloveeclipse commentedon Aug 11, 2026
After AI jumped into that while reviewing #4233, the root cause of the current behavior is this fix for this problem. The proposed AI fix is #4236.
File search: don't report shown elements as shown matches
File search: don't report shown elements as shown matches
File search: don't report shown elements as shown matches