DocumentManager should return the same IDocument or FileBuffer for 2 distinct (duplicate) resource sharing same URI

[treilhes]

Hello,

While trying to solve some LSP4E issue a major issue did arise.

Eclipse provide the following feature:

• For the same file uri, eclipse allows more than one editor to edit the same file

But the LSP protocol identify edited document by uri and not by IResource meaning:

• It is not possible to create an editing session for each editor editing the same file

So it means eclipse is in front of a crossroad:

• use the same IDocument for all editors and keeps them in sync or disallow multiple editors using the same language server to edit the same file (like Vscode)
• OR promote a new LSP protocol allowing to identify an editing session with something more than the file uri

Currently when your workspace contains a maven/gradle multi module project (which is far from a rare case) files are accessible from more than one IResource and can be edited by more than one editors. It causes bugs and side effects because lsp4e can't reliably associate an IResource/IDocument to a language server request. Lsp4e did try to lessen the issue by always choosing the most nested IResource but it is error prone and far from ideal. In this case user experience is highly impacted.

I hope this issue will allow to engage the discussion to be able to find a way out of this mess.

For those who want a more detailed explanation please see:
eclipse-lsp4e/lsp4e/pull/259
eclipse-lsp4e/lsp4e/issues/258

[mickaelistria]

I'm retitling the issue into something that is more meaningful from Platform POV.
The idea is that 2 distinct IResource that actually point to the same URI would most likely better use the same IDocument when open in an editor. This would most likely improve a lot of synchronization, including with LSP4E.