CodeActionKind filtering

[kjeremy]

Since CodeActionKind can be specified as a hierarchy or explicitly listed out in the capabilities does that mean that filtering via CodeActionContext.only is really a match against the beginning of the string?

[rchl]

Since I've been implementing this in Sublime's LSP client, I can share some practical experience.

As far as servers behave, the server should really only receive (through CodeActionContext.only) the exact kind it has specified as being supported through codeActionProvider. codeActionKinds. So if the server specifies source.fixAll.eslint as being supported, it would be the client's responsibility to send it exactly that, even if user has specified more generic source.fixAll.

[dbaeumer]

Yes, the idea is that the server for example should return all refactoring code actions if asked for CodeActionKind.Refactor.

@rchl please note that for backwards compatibility a client can still ask a server for code action with no context since this was the initial implementation.

[rchl]

@rchl please note that for backwards compatibility a client can still ask a server for code action with no context since this was the initial implementation.

Yes. And if the server does not understand CodeActionContext.only, it might reply with all code action types and then the client's responsibility is to filter those results to only match what the user requested.

Note that I'm talking in the context of user-configurable "Code actions on save" feature which is really an editor rather than spec feature.

[dbaeumer]

For the code action on save you are correct. And there was an bug in VS Code which didn't handle this correctly but that got fixed.

[dbaeumer]

I will close the issue. Please ping if there is any action that we should apply to the spec.