Missing features in MetaModel

[dbaeumer]

From microsoft/language-server-protocol#67 (comment)

• TraceValue has "compact" in meta model but not in published spec
• NotebookDocumentSyncClientCapabilities has executionSummarySupport in meta model but not in published spec
• PrepareRenameParams might be missing WorkDoneProgressParams as a base in published spec? (it's in meta model)
• In meta model, InitializeParams extends WorkspaceFoldersInitializeParams which does not mark workspaceFolders as optional (only nullable), but in the TS spec, it's both optional (?) and nullable: workspaceFolders?: WorkspaceFolder[] | null;
• Documentation is missing for quite a few things (it's in source TS, but missing in meta model):
  • CodeAction.disabled.reason ("Human readable description of why the code action is currently disabled.")
  • completionItem.commitCharactersSupport ("Client supports commit characters on a completion item.")
  • CompletionTriggerKind ("How a completion was triggered")
  • Many (all?) enums (eg.: CodeActionKind.Empty, CodeActionTriggerKind.Automatic)

I opened #945 to address some of the typos and truncated docs (I don't believe it addresses any of the above though).

[KamasamaK]

The following ErrorCodes are in the LSP Meta Model, but not part of the Markdown spec.

• MessageWriteError
• MessageReadError
• PendingResponseRejected
• ConnectionInactive

[DanTup]

@dbaeumer I created a PR for one of the issues above because it's one that's blocking me:

#948

If you've already started this, feel free to ditch it. The other issues are less important for me (although fixing the docs would be good, it would reduce my diff quite a lot - if it doesn't require a lot of knowledge about how the model is built, I could take a look at that too).

Edit: I was curious so had a look at enum docs too -> #949

[dbaeumer]

@KamasamaK thanks. I need to remove those form the meta model since they are error code implementation specific to vscode-jsonrpc.

[DanTup]

• (Not sure if worth fixing, but) some items have odd names because of TypeScript reserved words such as MonikerKind.$export
  This can result in odd generated names if a user of this model is using some other pattern to handle their own reserved words (which might not match TS). Perhaps drop the leading $ from any names?
• CompletionItem.itemDefaults has a data field in meta model, but it's not in the published web spec
• SemanticTokenTypes has decorator in meta_model, but it's not listed in the web spec

[DanTup]

@dbaeumer not sure if here is a good place for questions like this, but in the meta model, SemanticTokensClientCapabilities has this in the requests field:

	"name": "range",
	"type": {
		"kind": "or",
		"items": [
			{
				"kind": "base",
				"name": "boolean"
			},
			{
				"kind": "literal",
				"value": {
					"properties": []
				}
			}
		]
	},
	"optional": true

It's not clear what the literal here is intended to be (in the web spec, it's range?: boolean | {};. Is this the same as LSPObject? LSPAny? I'm trying to understand how my deserialisation should handle this (right now I'm producing a class that basically has no fields and will always deserialise/serialise to an empty object).

[dbaeumer]

@DanTup no it is not LSP any. It is basically an object literal with no properties. We did this sine we expect properties to be added which is easier if a object literal is already specified.

[dbaeumer]

See #954

[DanTup]

@dbaeumer thanks!

I found an issue where the specs don't match for NotebookDocumentSyncOptions - see #955.

I think things are close now though - the diff between my TS/JSON versions has shrunk considerably, thanks for your work on this! :-)

[DanTup]

@dbaeumer ServerCapabilities.experimental is currently typed as T:

{
	"name": "experimental",
	"type": {
		"kind": "reference",
		"name": "T"
	},
	"optional": true,
	"documentation": "Experimental server capabilities."
}

With a definition for T like:

{
	"name": "T",
	"properties": []
},

Is this intended? (T seems like an odd name, it doesn't seem like the type is generic in any way), or should it be LSPAny or similar?

[dbaeumer]

Done. Is now LSPAny.

[DanTup]

@dbaeumer great, thanks! FWIW the definition of T is still there but seems unnecessary (it's not referenced).

[dbaeumer]

Let me have a look then.

[dbaeumer]

Fixed here: #987