File search: don't report shown elements as shown matches

[iloveeclipse]

FileSearchPage#getLabel() compared the number of shown leaf elements with the number of matches and rendered the result with the "showing {1} of {2} matches" message. In the tree layout of a text search a leaf is a matching line, and a line can contain more than one match, so the label claimed that matches are hidden although everything was shown, and the reported number was a line count and not a match count.

The content provider is the only component that knows what is really shown, since it applies the element limit. It now reports

• how many leaf elements it shows and how many it would show without the element limit (LeafCounts), and
• how many matches are represented by the shown elements.

The page uses those numbers to only report a truncated result if the element limit really hides something, and to report matches (not lines) in the "showing {1} of {2} matches" message and files in the "showing {1} of {2} files" message.

As the counts are computed on the model instead of on the SWT widgets, the label is also correct if the viewer isn't populated yet, and the matches hidden by match filters are now counted independently from the element limit. This also allows to remove the widget traversal from the page.

Fixes #3720

Assisted-by: Github Copilot (Claude Opus 5)

Agent explanation:

Root cause of #3720

In FileSearchPage.getLabel() :

int itemCount = fContentProvider.getLeafCount(result);   // ELEMENTS (files or lines)
if (showLineMatches()) {
    int matchCount = result.getMatchCount();             // MATCHES
    if (itemCount < matchCount) { ... "showing {1} of {2} matches" ... }

Two different units are compared and an element count is rendered as a match count. Before commit 9cfdcbb (2024) that branch was dead code (it was guarded by viewer instanceof TableViewer while showLineMatches() requires the tree layout); that commit made it live, and since then the tree layout reports the number of matching lines as the number of shown matches. Because a line can hold several matches, the label claims results are hidden even when nothing is truncated — exactly "shown file count vs shown match count".

The PR #4233 commit keeps that structure and papers over it with a new message plus an O(lines × matches) recount on the UI thread every 500 ms.

Principle: the content provider is the only component that knows what is really shown (it owns the element limit), so let it report the numbers, computed on the model, not on the SWT widgets.

IFileSearchContentProvider

record LeafCounts(int shown, int all) { boolean isTruncated() { return shown < all; } }
LeafCounts getLeafCounts(Object parentElement);      // replaces getLeafCount(Object)
int getShownMatchCount(AbstractTextSearchResult r);  // matches represented by shown elements

FileTreeContentProvider

• one allocation‑free recursive walk of fChildrenMap produces both counts, mirroring exactly the per‑parent truncation done by getChildren() (children of a hidden node are hidden too). Cheaper than the old getLeafCount, which allocated an array per node.
• getShownMatchCount() collects the shown leaves and then iterates the matches of each affected file once, instead of scanning a file's whole match set once per line (that was the O(lines × matches) trap).

FileTableContentProvider: shown/total element counts, and shown matches summed over the shown elements.

FileSearchPage.getLabel()

• the "limited" message is emitted only if leafs.isTruncated(), i.e. only when the element limit really hides something → the false "showing 12 of 20 matches" is gone;
• tree/text search reports matches (getShownMatchCount of result.getMatchCount()), flat/file‑name search reports files — both messages now get numbers in their own unit, and no new NLS key/translation is needed;
• filteredOut is now the number of matches hidden by filters only (getMatchCount() - getUnfilteredMatchCount()), so truncation is no longer double‑counted as "filtered from view";
• removed getFilteredMatchCount(), both getRootElements(...) and both getMatchCount(...) helpers plus the Tree/Table/Item imports — the label no longer depends on populated widgets (no transient "showing 0 of N", no UI‑thread requirement, testable).

Net: FileSearchPage −106/+51 lines, and the label logic has a single source of truth.

[iloveeclipse]

Disclaimer : this is fully AI generated patch proposed by AI after review from #4233, which seem to work.

I will let the tests run and mark it as a draft for now, as I will not have time to proceed.

[eclipse-platform-bot]

This pull request changes some projects for the first time in this development cycle.
Therefore the following files need a version increment:

bundles/org.eclipse.search/META-INF/MANIFEST.MF

An additional commit containing all the necessary changes was pushed to the top of this PR's branch. To obtain these changes (for example if you want to push more changes) either fetch from your fork or apply the git patch.

Git patch

From 458f1ef17abf9b866e8617903b856eeaddb2e8e8 Mon Sep 17 00:00:00 2001
From: Eclipse Platform Bot <platform-bot@eclipse.org>
Date: Tue, 11 Aug 2026 15:31:21 +0000
Subject: [PATCH] Version bump(s) for 4.41 stream


diff --git a/bundles/org.eclipse.search/META-INF/MANIFEST.MF b/bundles/org.eclipse.search/META-INF/MANIFEST.MF
index 726e86f7ca..969c9033d3 100644
--- a/bundles/org.eclipse.search/META-INF/MANIFEST.MF
+++ b/bundles/org.eclipse.search/META-INF/MANIFEST.MF
@@ -2,7 +2,7 @@ Manifest-Version: 1.0
 Bundle-ManifestVersion: 2
 Bundle-Name: %pluginName
 Bundle-SymbolicName: org.eclipse.search; singleton:=true
-Bundle-Version: 3.19.0.qualifier
+Bundle-Version: 3.19.100.qualifier
 Bundle-Activator: org.eclipse.search.internal.ui.SearchPlugin
 Bundle-ActivationPolicy: lazy
 Bundle-Vendor: %providerName
-- 
2.54.0

Further information are available in Common Build Issues - Missing version increments.

[Copilot]

Pull request overview

Fixes issue #3720 by reporting visible search matches/files accurately.

Changes:

• Adds model-based leaf and match counting.
• Updates result labels for limits and filters.
• Adds regression tests and increments the bundle version.

Reviewed changes

Copilot reviewed 7 out of 7 changed files in this pull request and generated 2 comments.

Show a summary per file

File	Description
SearchResultPageLabelTest.java	Tests label counts and truncation.
AllFileSearchTests.java	Registers the new tests.
IFileSearchContentProvider.java	Defines counting APIs.
FileTreeContentProvider.java	Counts visible tree leaves and matches.
FileTableContentProvider.java	Counts table elements and matches.
FileSearchPage.java	Builds labels from provider counts.
MANIFEST.MF	Increments bundle version.

---

💡 Add a code-review agent skill or configure MCP servers for context-aware, tailored reviews. Learn more in the docs.

[github-actions]

Test Results

   858 files  ± 0     858 suites  ±0   57m 41s ⏱️ - 1m 23s
 8 162 tests + 5   7 919 ✅ + 5  243 💤 ±0  0 ❌ ±0 
20 388 runs  +15  19 734 ✅ +15  654 💤 ±0  0 ❌ ±0 

Results for commit ca66172. ± Comparison against base commit d5c3e7f.

♻️ This comment has been updated with latest results.

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.

Suppressed comments (1)

bundles/org.eclipse.search/search/org/eclipse/search/internal/ui/text/FileSearchPage.java:473

• The new calculation separating match-filtered results from element-limit truncation is not covered by the added label tests. Please add a case with an active match filter and a truncating element limit, asserting that the “matches filtered from view” count includes only filter-rejected matches while the limited qualifier reports the independently hidden matches.

				int filteredOut = result.getMatchCount() - getUnfilteredMatchCount(result);

[Copilot]

Pull request overview

Copilot reviewed 7 out of 7 changed files in this pull request and generated no new comments.