Support allCommitCharacters even if the client announces commit characters per item.

[DanTup]

'm using the client library here for LSP support in a VS Code extension. My server is sending a dynamic registration that includes commit characters like this:

{
	"id": "3",
	"method": "textDocument/completion",
	"registerOptions": {
		"documentSelector": [
			{
				"language": "dart",
				"scheme": "file"
			}
		],
		"triggerCharacters": [
			".",
			"=",
			"(",
			"$"
		],
		"allCommitCharacters": [
			".",
			"("
		],
		"resolveProvider": true
	}
},

However pressing the commit characters doesn't seem to have any effect. It's enabled in VS Code and it works as expected for TypeScript. Is there anything else I need to do?

[dbaeumer]

This can only be used for clients that don't support individual commit character on individual completion items.

See https://github.com/microsoft/vscode-languageserver-node/blob/master/protocol/src/common/protocol.ts#L1664

This field can be used if clients don't support individual commmit characters per completion item. See ClientCapabilities.textDocument.completion.completionItem.commitCharactersSupport

Since VS Code supports individual commmit characters per completion item it will not honor this during registration.

[dbaeumer]

Is this OK for you?

[DanTup]

@dbaeumer I think the wording on the spec should be clearer if it will only be used by clients that don't support it. Right now it seems like clients can use both.

But - is there any reason this can't be supported? The payload size for completion is already quite a real issue and duplicating the same array on every single item is needlessly wasteful. It would be much nicer if this could be supported (either here on the registration, or on a single property for the whole completion list) IMO.

[dbaeumer]

Technically there is nothing that prevents us from implementing it. It is simply not done.

[DanTup]

btw, in the spec it has this:

	 * If a server provides both `allCommitCharacters` and commit characters on an individual
	 * completion item the ones on the completion item win.

This reads like it's reasonable to provide both, and that the client would fall back to allCommitCharacters if it's not set on the completion (otherwise it wouldn't really make sense to send both).