Add support for VSCode-specific editor.action.showReferences command

[jwortmann]

The editor.action.showReferences command is technically not part of the protocol (see microsoft/language-server-protocol#788 - the last comment therein from 2024 suggests that they are open to standardize relevant commands, but it seems there was no follow up to that, so I'd say we shouldn't wait for that - or we would possibly wait indefinitely).

This command is used by various servers for "References" code lenses. There are a few custom implementations to handle it on the plugin side in LSP-typescript, LSP-elm, LSP-volar, LSP-vue and LSP-PowerShellEditorServices, which look all identical: https://github.com/search?q=org%3Asublimelsp%20editor.action.showReferences&type=code

A similar middleware is also required in VSCode extensions to translate the JSON arguments into vscode.Uri, vscode.Position and vscode.Location objects, that are accepted by the built-in VSCode command. But since these objects have a direct correspondence to the JSON types from the LSP specs, we can probably assume that the arguments from the server always match those types, when the command name is editor.action.showReferences.

The advantage of having this implementation directly in LSP is that such code lenses would work automatically and even for manual server configs that don't have a helper package. If there is a custom implementation in a plugin, that still takes precedence, because we ask the plugin first:

LSP/plugin/core/sessions.py

Lines 1332 to 1336 in d9cf1f7

	if self._plugin:
	task: PackagedTask[R | Error | None] = Promise.packaged_task()
	promise, resolve = task
	if self._plugin.on_pre_server_command(command, lambda: resolve(None)):
	return promise

This even allows to override the implementation from LSP in case a server would decide to use different command args for the same command name. But for the plugins which are mentioned above, the custom implementation basically becomes obsolete.

---

By the way, I'm considering to maybe refresh the LocationPicker a bit (because currently it just puts the server name as annotation on the righthand side of each entry - maybe we could use that space in a better way for this application), but it should be good for now and that can wait.

[rchl]

Should we also add editor.action.triggerSuggest and editor.action.triggerParameterHints?

[jwortmann]

Probably not relevant for code lenses, I guess?

[rchl]

I did not know that this is for code lenses. The name is not very specific.

[jwortmann]

It's currently only used for code lenses, but I think I'd keep the variable name because it's not wrong and could possibly proof useful for something else in the future.
I could add these two other commands as well, but I don't think it would make a difference, and in the unlikely case that a server would actually use one of those commands for a code lens, I'd probably rather keep that code lens hidden :)