Fix visible non-workspace editor context for chat

[mralonsocorona]

Summary

Fixes current-editor chat context for visible Eclipse text editors that expose an IDocument but are not backed by a workspace IFile, such as JDT class-file/source-attachment editors.

The existing workspace IFile path remains unchanged. When no workspace file is available, the active visible editor document is exposed through a read-only internal copilot-visible-editor://... URI, and workspace/readFile can resolve that URI through the referenced-file service.

Fixes #117.

Details

• Keeps IFile current-editor context as the first-priority path.
• Adds URI-based current-editor fallback support to IReferencedFileService.
• Adds read-only visible-editor snapshot support for non-IFile text editors.
• Keeps FileUtils.readFileWithStats(...) as the primary workspace/readFile path.
• Falls back to the visible-editor snapshot only when the normal read returns the existing file not found: <uri> result.
• Does not add a JDT dependency, hidden workspace project, indexing, or writable file semantics.

Validation

• git diff --check
• ./mvnw checkstyle:check
• ./mvnw test

[mralonsocorona]

@microsoft-github-policy-service agree

[Copilot]

Pull request overview

This PR improves current-editor chat context handling for visible Eclipse text editors that expose an IDocument but are not backed by a workspace IFile (e.g., JDT class-file/source-attachment editors). It does so by introducing an internal, read-only copilot-visible-editor://... URI for the current visible editor and enabling workspace/readFile to resolve that URI via the referenced-file service when the normal workspace file read returns “file not found”.

Changes:

• Extend IReferencedFileService with optional methods to expose a non-workspace current-editor URI and to read that editor’s snapshot text.
• Add visible-editor snapshot tracking in the UI referenced-file service and generate stable internal URIs for it.
• Update workspace/readFile to fall back to the visible-editor snapshot only when FileUtils.readFileWithStats(...) yields the existing “file not found: ” result, with new unit tests covering the fallback behavior.

Reviewed changes

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

File	Description
com.microsoft.copilot.eclipse.ui/src/com/microsoft/copilot/eclipse/ui/chat/services/ReferencedFileService.java	Tracks a read-only snapshot + internal URI for non-IFile visible text editors and serves snapshot reads via IReferencedFileService.
com.microsoft.copilot.eclipse.core/src/com/microsoft/copilot/eclipse/core/lsp/CopilotLanguageClient.java	Uses the new current-editor URI fallback for conversation context and adds workspace/readFile fallback to the visible-editor snapshot on “file not found”.
com.microsoft.copilot.eclipse.core/src/com/microsoft/copilot/eclipse/core/chat/service/IReferencedFileService.java	Adds default methods for current-editor URI exposure and snapshot reads (non-breaking for other implementations).
com.microsoft.copilot.eclipse.core.test/src/com/microsoft/copilot/eclipse/core/lsp/CopilotLanguageClientTests.java	Adds tests for current-editor URI resolution and readFile fallback behavior.

[jdneo]

Looks like this pr only handles for the current file, what about user manually attached .class files? Will that belong to this PR's scope?

[mralonsocorona]

Thanks for raising this.

I intentionally kept this PR scoped to the current-editor path because that is the behavior described in #117: the user has a visible Java source/class-file editor, but chat cannot use that visible editor content as context.

Manually attached ".class" files seem related, but I think they are a separate path from the current-editor context. Supporting that properly would likely require extending the referenced-file attachment flow/content resolution as well, rather than only the current-editor fallback added here.

My preference would be to keep this PR focused on the visible current editor, and handle manually attached ".class" files in a follow-up PR if you agree.

[jdneo]

Thank you. I'm fine with that.