Ignore didOpen didClose for non-visible files

[Arthurm1]

textDocument/didOpen and textDocument/didClose get fired off from VSCode everytime a Metals sends a textDocument/definition message for a non-opened file.

e.g. Hover over java.util.LinkedList and Metals will send a textDocument/definition with the URI file:///workspacepath/.metals/readonly/dependencies/src.zip/java.base/java/util/LinkedList.java

Then VSCode will send a textDocument/didOpen and immediate textDocument/didClose for this URI even though the user doesn't see the file.

This causes Metals to compute a number of things for the LinkedList file in MetalsLanguageServer#didOpen and MetalsLanguageServer#didClose which I think are unnecessary as the file isn't seen.

There's no additional data in didOpen/didClose to indicate visibility and allow Metals to ignore these messages but I see that here the C++ language server gets round this by producing its own didOpen/didClose messages by handling the onDidChangeVisibleTextEditors event.

I was wondering if it was possible to do something similar in Metals - just to cut down on unnecessary processing.

[tgodzik]

Thanks for raising this! I remember that I had the same from with the decorations, which cache the currently focused semanticdb file. The focused file would switch without opening an actual file. ,This made me realize it's an in-build VS Code thing due to how documents are opened.

There was an issue about it: microsoft/vscode#78453

And a proposal to expose open editors: microsoft/vscode#15178 (haven't read it fully)

We could have our own didOpen/didClose events to get around it for sure, but it would be cool handle it on the VS Code side. We would also make sure that we handle the normal events for non-vscode editors.