`CompletionItemKind` should have `supportsCustomValues` set to true

[debonte]

The LSP documentation states that the client should gracefully handle values outside of its known set:

completionItemKind?: {
		/**
		 * The completion item kind values the client supports. When this
		 * property exists, the client also guarantees that it will
		 * handle values outside its set gracefully and falls back
		 * to a default value when unknown.
		 *
		 * If this property is not present, the client only supports
		 * the completion item kinds from `Text` to `Reference` as defined in
		 * the initial version of the protocol.
		 */
		valueSet?: [CompletionItemKind](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.18/specification/#completionItemKind)[];
	};

Therefore, I would expect that the description of CompletionItemKind in the meta model would have supportsCustomValues set to true, so tools that consume the meta model would understand that unspecified values are allowed. Currently it does not:

		{
			"name": "CompletionItemKind",
			"type": {
				"kind": "base",
				"name": "uinteger"
			},
			"values": [
				{
					"name": "Text",
					"value": 1
				},
				{
					"name": "Method",
					"value": 2
				},
				{
					"name": "Function",
					"value": 3
				},
				{
					"name": "Constructor",
					"value": 4
				},
				{
					"name": "Field",
					"value": 5
				},
				{
					"name": "Variable",
					"value": 6
				},
				{
					"name": "Class",
					"value": 7
				},
				{
					"name": "Interface",
					"value": 8
				},
				{
					"name": "Module",
					"value": 9
				},
				{
					"name": "Property",
					"value": 10
				},
				{
					"name": "Unit",
					"value": 11
				},
				{
					"name": "Value",
					"value": 12
				},
				{
					"name": "Enum",
					"value": 13
				},
				{
					"name": "Keyword",
					"value": 14
				},
				{
					"name": "Snippet",
					"value": 15
				},
				{
					"name": "Color",
					"value": 16
				},
				{
					"name": "File",
					"value": 17
				},
				{
					"name": "Reference",
					"value": 18
				},
				{
					"name": "Folder",
					"value": 19
				},
				{
					"name": "EnumMember",
					"value": 20
				},
				{
					"name": "Constant",
					"value": 21
				},
				{
					"name": "Struct",
					"value": 22
				},
				{
					"name": "Event",
					"value": 23
				},
				{
					"name": "Operator",
					"value": 24
				},
				{
					"name": "TypeParameter",
					"value": 25
				}
			],
			"documentation": "The kind of a completion entry."
		},

[dbaeumer]

supportsCustomValues is meant differently. The idea is that clients and servers can introduce their own values (for example around semantic tokens). This is not the case for CompletionItemKind

[debonte]

@dbaeumer, I wonder if the description of the completionItemKind client capability is misleading then. Specifically the part where it says that the client will handle values outside of the set it specifies. Looking at other areas of the spec though, I'm now thinking that this comment is focused on back/forward compat scenarios? Maybe that should be clarified here.

completionItemKind?: {
		/**
		 * The completion item kind values the client supports. When this
		 * property exists the client also guarantees that it will
		 * handle values outside its set gracefully and falls back
		 * to a default value when unknown.
		 *
		 * If this property is not present the client only supports
		 * the completion items kinds from `Text` to `Reference` as defined in
		 * the initial version of the protocol.
		 */
		valueSet?: [CompletionItemKind](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#completionItemKind)[];
	};

For reference, here's the original lsprotocol issue that led to us filing this -- microsoft/lsprotocol#344