Multifile context not supported in Eclipse plugin?

[HHartvig]

Using Eclipse 4.31 and Copilot 0.10.0 eclipse plugin.
When adding multiple files as context in the chat window, it seems that copilot only cares about the first one, and can see the others.

I fails regardless of using agent or ask mode.

[jdneo]

Do you mean the editor has multi-page, each one has its own file?

[HHartvig]

Do you mean the editor has multi-page, each one has its own file?

No. I have two editors open. One with each file. I have then used the "Add Context" to add the second file as context, but it's still not being picked up, even though you can see it in the chat window.

[jdneo]

I tried for java file and it works

Not sure about the step up of PLI files. Is there any steps that I can try to reproduce?

[HHartvig]

I dug a little deeper. It's not down to the file type, but could be a symptom related to the project the files resides in.

I have tried with different types of files, and as long as they reside in a local project in Eclipse it works fine adding multiple files. But when I add files opened from projects that are shared with our SCM then it does not work with multiple files, but only one file is picked up.

Our SCM is an IBM developed SCM, and in an recent update they have "hidden" the project natures of their projects. Don't know if this is causing it, or if these project natures somehow disturb? Picture below is showing my local project on the left and SCM project on the right. Bot projects are residing in the same workspace. If I copy files from the SCM project to the local project, it works fine as mentioned. I don't know if this can bring you in any direction on this?

[HHartvig]

Ok. It get's even more strange from here. If I create a local project with zcomponent natures, I can still work on multiple files using Copilot. Once I share this project with our SCM "Jazz Source Control" (not git), then it stops working and it only picks up one file from the context, even though its the same files as before.

[HHartvig]

It there a way to enable some more logging in the copilot plugins, so maybe we can chase this down. Let me know how I can help.

[jdneo]

Does that mean the 'not working' files are stored out of the project?

[HHartvig]

No. All files that I have tried with are stored in projects. And they are all valid IResources.

Copilot picks up more files when they are stored in a non "team" project.

But when the project is shared with "Jazz Source Control" then it only recognize one file regardless of how many I add as context.

[jdneo]

I'm assuming that the uri of the Jazz Source Control might not be a file scheme uri?

We can check the payload. You can do:

1. Open the language server console logging

2. Save and restart Eclipse
3. Add some context file and send, you should be able to see the payload

[HHartvig]

Spot on. The second file is being picked up as URI, regardless of them being placed in the same folder.

[jdneo]

Thank you. that file might just simply be dropped at the copilot language server side. Because the server does not know how to get its content.

Need to investigate how to fix it

[HHartvig]

Sounds great. I have cloned the Copilot Repo, and made it run, so if there is anything that can be done in the plugins before they interact with the Language Server Part, then I might be able to help. Let me know if there are classes that are more interesting than others to look into.

What strikes me as odd though is that these two files are place the exact same place, and the one in the open editor is picked up correctly by it's file:path, the added one does not even though this is also open in the editor.

[HHartvig]

I know this is not the correct fix. But I managed to change the FileChatReference to use the FileUtils.getResourceURI instead of using the getLocationURI as default.

This does the trick from our end. Off course FileUtils will fall back to getLocationURI if there is no Location, which will still make the Language Server unhappy. But I don't know which cases that would be? Is that if you add external files?

Anyways. The same fix needs to be applied to DirectoryChatReference of course, if this is the way forward.

[HHartvig]

Any news on this. Could it be part of the nightly build?

[jdneo]

Ah, sorry I somehow missed the reply.

What strikes me as odd though is that these two files are place the exact same place, and the one in the open editor is picked up correctly by it's file:path, the added one does not even though this is also open in the editor.

My understand on this issue now is: Because for those open editors, the client side (plugin itself) will send the textDocument/didOpen (contains the content of the file) to Copilot Language Server. And CLS will cache its content, that's why there are all available in the context.

For those files that are not opened in editor, CLS has to read its content from disk, and when the scheme of the uri is not file, it skips it. So the fix might happen on CLS side I guess.

But I managed to change the FileChatReference to use the FileUtils.getResourceURI instead of using the getLocationURI as default.

Interesting, how does the payload looks like after this change on you side?