I want to discuss an issue I briefly talked in private email with Mickael, but needs to be re-summarized, and discussed in public.
I first came across this in the context of auto-save, but it applies for LSP as well. It relates to
https://bugs.eclipse.org/bugs/show_bug.cgi?id=508488 , but is a more general Eclipse problem.
Basically, in Eclipse you can have multiple
workspace files that have the same file-system location: If they are under linked folders, or more commonly, when using nested projects.
The problem is, if you open those files, they will be
backed by different text buffers in the editor. It is also possible, API wise (using `
FileBuffers.getTextFileBufferManager().connectFileStore(...)` ), to open a file using a file-system external location even though the file exists in the IResource model, and doing this will also get you a different buffer for each editor, even though it's the same location.
This is inadequate for the LSP model, or really any IDE that uses external tools for analysis, since they effectively require only one text buffer per file-system location. I would say that from an IDE UX perspective, it also doesn't make much sense to have different buffers for the same file-system location, so I'm not even sure why Eclipse tries to support this case anyway (might have been incidental behaviour, not intentional?)
Mickael mentioned that one way to ameliorate this problem is to use the Project Explorer hierarchical project layout. That does help, since it exposes only one of the IFile's in the explorer UI. However this is still a leaky abstraction that can be broken in other ways. One way is using Open-Resource/Open-Type, or Search to open a different IFile. Another one (common for me) is opening a file from the Git Staging view, from the Git History view. Yet another way to break things (a bit more convoluted but not as uncommon as you might think) is to open an external file (either drag-and-drop into Eclipse, or open from Git repositories, or even getting there from code-completion), and then import the project containing that file into Eclipse - making the external location now available as an IFile.
One way to fix this issue on the plug-in side, for an editor that is contributed by the plug-in, is to use a TextFileDocumentProvider/IDocumentProvider that always connects to the buffer using FileBuffers.getTextFileBufferManager().connectFileStore(...). This will ensure we always gets a unique buffer per location. It will have some other minor API consequences though, for example, editor saves will not automatically/immediately appear in IResource deltas. (only when the resource is refreshed elsewhere) This seems fine, as I imagine that the whole IResource delta mechanism is not going to be used by external tools anyway. Definitely not in LSP. There might be some other challenges to make this approach work though, like making sure Problem markers/annotations still work.
Another way to address this issue would be to try to get a canonical IFile based on that IFile locations, and a map registry of opened IFiles. But it would not fix things in all cases as it would still tie the editor to an IFile.
From my own experience, I would say the best future for Eclipse IDEs based on external tools is for them to wean themselves off the IResource model as much as possible.
