add support for LSP workspace/executeCommand message for initial use with Scala Metals

[StephenWithPH]

I'm using Metals via https://github.com/dense-analysis/ale/blob/master/ale_linters/scala/metals.vim (thanks, @zoonfafer!)

Metals needs users to import the build upon first use within a workspace (i.e., a Scala project). Once you do that, the Metals server exposes all the goodies necessary for a rich user experience.

To tell the Metals server to import the build, you POST to its /execute-command endpoint with command=build-import:

curl -XPOST http://localhost:5031/execute-command?command=build-import

The first time one does this in a project, it takes a while. Subsequent invocations take much less time.

Is there some standard pattern for this sort of thing in ALE's plugin ecosystem?

[zoonfafer]

Would like to know about it also.

As a starting point, I would imagine the following might be relevant?

• https://github.com/dense-analysis/ale/blob/master/autoload/ale/lsp/message.vim Perhaps a new function ale#lsp#message#ExecuteCommand(buffer, command) could be implemented here.
• ale#lsp#Send(conn_id, message) - https://github.com/dense-analysis/ale/blob/2b785688ead505dcbc1007374d3dca9914aa247a/autoload/ale/lsp.vim#L542-L560

[StephenWithPH]

Having done more research, Metals' http approach is there only as a fallback for users when their LSP client doesn't support workspace/executeCommand (or other LSP methods):

The most popular LSP clients in editors like Vim currently have limited support so that endpoints like window/showMessageRequest are ignored, with no workaround for users to interact with the Metals language server. This http client allows users in those editors to trigger server commands and respond to UI dialogues through their browser instead.

(https://github.com/scalameta/metals/blob/a75b5f61577d2270ed435d956627ab5a7b996482/metals/src/main/scala/scala/meta/internal/metals/MetalsHttpClient.scala#L39-L43)

---

Perhaps a new function ale#lsp#message#ExecuteCommand(buffer, command) could be implemented here.

@zoonfafer ... I agree that adding standard LSP client support for workspace/executeCommand (relevant LSP spec) is the proper approach. This is far better than any http workaround.

We would also need to update the capabilities here: https://github.com/dense-analysis/ale/blob/2b785688ead505dcbc1007374d3dca9914aa247a/autoload/ale/lsp.vim#L361-L371

Given this change would add capabilities relevant for any LSP server that ALE can handle, I think it's reasonable to ask for @w0rp 's thoughts...

@w0rp : does the above approach seem reasonable?

[w0rp]

Sending the workspace/executeCommand messages via a command in ALE is fine to do, as long as the code is simple enough. This may be related to "Code Actions" in some way. There's an issue for "Code Actions" here: #1466

[dassio]

this is will also be really helpful for starting the eclipselsp DAP, right now vimspector are using YCM to do this one, but this could be made possible by ALE:

Ultimately, the way the debug server is started is: something, somewhere starts up a jdt.ls instance with the debug adapter "bundle" passed as an additional initialisation option, and connects to it. In my case, this is my fork of ycmd. something provides the capability send a Language Server Protocol 'executeCommand' message to that jdt.ls instance (In my case, this is :YcmCompleter ExectuteCommand ) you execute the LSP command java.execute.workspaceCommand with arguments [ 'vscode.java.startDebugSession' ] (In my case, this is :YcmCompleter ExectuteCommand vscode.java.startDebugSession, as in the above demo)

https://github.com/puremourning/vimspector/issues/3#issuecomment-450359563