Include provider information in code actions

[MariaSolOs]

For filtering purposes in the client, it would be useful for code actions to include information about its provider, similar to how diagnostics have an optional source field.

[skewb1k]

I think it's important to show a clear need and real examples from existing language servers before adding yet another string field with arbitrary data. Otherwise, we just introduce extra work for clients to support and display it somewhere.

For client-side filtering, there's already the kind field, which is explicitly documented as: The kind of the code action. Used to filter code actions.

For context, this topic originally came up in neovim/neovim#36028 (comment) about one of Neovim's APIs for filtering code actions that only exposes the CodeAction object and therefore didn't support filtering by client. The proposed solution - adding a field for the server to pass its own ID - is a dead end. There's no need to reference server IDs after the initialization handshake, since the client already tracks active servers and can identify them without extra RPC overhead.

The existing source field in diagnostics is often used by servers to specify the linting rule, which is actually useful to users and makes sense to keep as a separate field rather than concatenating it into the title string. The kind field already serves a similar purpose for code actions, and I don’t see any case where it wouldn't be sufficient or would justify adding another field.

[MariaSolOs]

Otherwise, we just introduce extra work for clients to support and display it somewhere.

There's no extra work that needs to be done. Editors can decide to just not use this field.

For client-side filtering, there's already the kind field, which is explicitly documented as: The kind of the code action. Used to filter code actions.

Well kind is A filter, the source could be another one. Multiple code action providers can (and often do) set the same kind, and so having the source could offer a more granular filtering.

I don't seem to be the only one that sees value in having the source in a code action. @mfussenegger also proposed it in #2020 (review) as a way to identify AI-generated code actions.

[skewb1k]

Otherwise, we just introduce extra work for clients to support and display it somewhere.

There's no extra work that needs to be done. Editors can decide to just not use this field.

Of course they can, but do they really want to? What I'm trying to say is that we should respect the work of both client and server developers and set a high bar for justifying additions to the spec. While the protocol should remain flexible, the minimal bar for adding anything should be at least a theoretical use case, or ideally a real-world LSP implementation that actually needs it.

Quoting you from Matrix:

I agree that adding arbitrary bluff is useless, but I think that for code actions it might be helpful. With AI taking over editor tooling I can imagine multiple models providing actions with the same kind/title/description but then the user might want to filter out by a given model

Thanks for the example - that's exactly what was missing. Having a clear picture of the feature's purpose helps raise new questions:

• Should the field be an arbitrary string, or could the server predefine a set of allowed providers during init?

• Should it only apply to code actions, or might other methods (like inline completions) need it too?

• Should it be a top-level field in the response and named source? If it's provided without an LLMGenerated tag, what does the value actually mean? Maybe there is a reason to restrict to this specific domain.

And the only way to avoid guessing and choose the right design is to have at least some features and workflow requirements implemented - for example outside LSP in some editor. I may not be fully up to date with the latest trends, but it seems that no AI-powered editor or LSP server currently provides code actions from multiple sources. If such a scenario exists or emerges in the future, the appropriate way to address it would be to create a dedicated issue with title like: "Server X needs an LSP field to support feature Y in clients without a hack."

The source could also be helpful in sorting code actions,
where users might want to assign priorities to certain LSPs

I may be misunderstanding you here, but I want to emphasize again: servers and clients shouldn't use any fields after initialization to identify each other. If a client wants to provide an API to filter by server, it already has all the necessary information and should just expose it (like in case of Neovim). Even if a server were to provide this info in an field like source, a client cannot reliably depend on it because there's nothing forcing the server to a) provide it b) put its ID there.