New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(lsp): allow enable/disable inlay_hint by client_id
#28521
base: master
Are you sure you want to change the base?
Conversation
@@ -1649,13 +1651,14 @@ get({filter}) *vim.lsp.inlay_hint.get()* | |||
• {client_id} (`integer`) | |||
• {inlay_hint} (`lsp.InlayHint`) | |||
|
|||
is_enabled({bufnr}) *vim.lsp.inlay_hint.is_enabled()* | |||
is_enabled({bufnr}, {client_id}) *vim.lsp.inlay_hint.is_enabled()* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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")
is_enabled({bufnr}, {client_id}) *vim.lsp.inlay_hint.is_enabled()* | |
is_enabled({bufnr}, {filter}) *vim.lsp.inlay_hint.is_enabled()* |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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(?)
ad43007
to
fb0a481
Compare
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.
I know it's better to improve existing features rather than risk adding new ones now, but if we change By the way, the breaking change I originally thought was considering removing neovim/runtime/lua/vim/lsp/inlay_hint.lua Lines 106 to 116 in c5b9fb2
because it would be redundant if this PR is merged. (users know what bufnr and cilent_id is when they call this function)
If this feature is acceptable, I'm willing to add a lot of tests in this PR. |
we can do that in a backwards-compatible way without much trouble. |
I created #28523, convert this into a draft PR now. |
We cannot toggle inlay hints by clients in this way. |
The original idea was to provide API consistency, and if this was implemented then users could use
to enable inlay hints only for desired clients. Though you can close it on the server side, this provides more flexibility.