feat(lsp): allow enable/disable inlay_hint by client_id

[ofseed]

The original idea was to provide API consistency, and if this was implemented then users could use

if client.name == "lua_ls" then
  vim.lsp.inlay_hint.enable(not vim.lsp.inlay_hint.is_enabled(), { client_id = client.id })
end

to enable inlay hints only for desired clients. Though you can close it on the server side, this provides more flexibility.

[justinmk]

if more filters are being added then it's time to make this a "kwargs" arg instead of adding more parameters.

probably is_enabled({filter}) is best, though is_enabled({bufnr}, {filter}) could be acceptable (and bufnr=nil would be "all/any buffer")

Suggested change

	is_enabled({bufnr}, {client_id}) *vim.lsp.inlay_hint.is_enabled()*
	is_enabled({bufnr}, {filter}) *vim.lsp.inlay_hint.is_enabled()*

[mfussenegger]

If I understand the changes right, the same could currently be accomplished by changing the capabilities in the vim.lsp.start calls so that only the clients you want to use for inlay-hints indicate support for it.

Wouldn't that be good enough?

On a glance the diff looks quite impactful, I'd rather not merge this close to 0.10, especially not without tests covering this(?)

[ofseed]

Honestly, I originally wanted to create an issue to ask if it was worth completing, but I didn't want to use an issue to describe this feature, so I implemented it directly. Now it seems that the current implementation is indeed rather sloppy.

On a glance the diff looks quite impactful, I'd rather not merge this close to 0.10,

I know it's better to improve existing features rather than risk adding new ones now, but if we change is_enabled({bufnr}, {filter}) to is_enabled({filter}) after the release of 0.10, the breaking change will impact the stable users.

By the way, the breaking change I originally thought was considering removing vim.lsp.inlay_hint.get.ret

neovim/runtime/lua/vim/lsp/inlay_hint.lua

Lines 106 to 116 in c5b9fb2

	--- Optional filters |kwargs|:
	--- @class vim.lsp.inlay_hint.get.Filter
	--- @inlinedoc
	--- @field bufnr integer?
	--- @field range lsp.Range?
	--- @class vim.lsp.inlay_hint.get.ret
	--- @inlinedoc
	--- @field bufnr integer
	--- @field client_id integer
	--- @field inlay_hint lsp.InlayHint

because it would be redundant if this PR is merged. (users know what bufnr and cilent_id is when they call this function)

especially not without tests covering this(?)

If this feature is acceptable, I'm willing to add a lot of tests in this PR.

[justinmk]

but if we change is_enabled({bufnr}, {filter}) to is_enabled({filter}) after the release of 0.10, the breaking change will impact the stable users.

we can do that in a backwards-compatible way without much trouble.

[ofseed]

I created #28523, convert this into a draft PR now.

[ofseed]

If I understand the changes right, the same could currently be accomplished by changing the capabilities in the vim.lsp.start calls so that only the clients you want to use for inlay-hints indicate support for it.

Wouldn't that be good enough?

We cannot toggle inlay hints by clients in this way.