microsoft / microsoft/language-server-protocol

Clarify the intension of how commands are defined

Open
#432 11 comments 4 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

clarification commands discussion
Dominant language
TypeScript
Stars
13k
Forks
1k
Avg merge
6d 1h
Merged PRs (30d)
10

Description

There seems to be a great deal of confusion around the mechanism by which commands are defined.

Personally, my take on it is that commands 'exist' somehow on the client-side. I.e. there is client-side command registry. Any command that exists is somehow or other entered into this registry.

This registry functions like a global namespace into which every existing command irrespective of how it is/was defined, is entered.

So I imagine that, allthough the spec doesn't currently have standard list of commands the idea is that at some point in the future, a standardized list of commands might/will/should be created and added to the spec. And I assume this is the direction in which this part of the spec is intended to evolve.

I am also aware that there is now a registerCapability request that allows a server to explicitly request specific command ids be delegated to the server so that a server may implement these commands.

By my interpretation, this does not change the fact that ultimately, the command is still a client-side thing.
I.e. commands defined in this way still primarily exist as 'executable entities' on the client side (i.e. they are entered into the same global command registry as any other command that comes 'baked in' with the client). The client simply happens to implement these commands by delegating there execution to the server.

I think my interpretation is in-line with how this works in vscode. And so I feel confident this is the intended interpretation of the spec. But there are some who disagree with this and suggest that I may not be reading the spec right. (I must admit, a lot of my interpretation is read between the lines, and though it all seems logical to me, the spec doesn't say any of this very clearly, and leaves a lot of that wide open to interpretation).

For an example of the kinds of confusion that seems to be going on take a look at this:

https://github.com/atom/atom-languageclient/issues/183

The folks there seem to lean more towards an interpretation that there is no 'central command registry', but rather a command registry is 'private' to a single client <-> server connection. So that, for example any command requested to be executed by a given server (say by including it in code action) must be defined by that same server (so not, for example a 'baked in to the client' or 'defined by another server' command).

Can we please get some clarity on this? If not in the spec, at least some discussion here to try and reach some kind of consensus?

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Review the protocol specification's command-definition text and the registerCapability request, then compare the competing client-wide and connection-private interpretations described here and in atom/atom-languageclient#183. Done means reaching consensus on command scope and documenting that behavior clearly in the specification.

Written by the indexing model from the issue text.

Assessment

Domain
api, documentation
Issue type
Documentation
Difficulty
5/5
Estimated time
Over a week
Activity status
Stale
Clarity
Needs clarification
Newbie friendliness
25/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.