Yi Ming

> 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...

> Is that "race" because of our internal design or because of interactions with the LSP server? To get code lenses to be shown on these buffers, there will be...

By the way, let me explain the second situation in this PR description in detail. According to the [LSP specification](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#command), the `CodeLens.command` is optional but the `CodeLens.command.command` is not optional,...

I kept the commit history as clean as possible to make it easier to review. Thereby reducing the risk of merging this PR before the release of 0.10.

@MariaSolOs More explanations for why make `bufstates` as a `vim.defaulttable`: 1. To make `bufstate`s inherit values from the `globalstate`, we need `setmetatable` for them. Instead of defining a factory function...

Since you mentioned this life cycle management issue, I wonder if I should change the way `bufstates` are managed here before this PR is merged. I explained [above](https://github.com/neovim/neovim/pull/28543#issuecomment-2081686918) why using...

IMO the current behavior of `enable` is good enough, even if we provide something like `vim.g.inlay_hint = true` and `vim.b.inlay_hint = false`, we should keep the current behavior. A summary...

Not sure if it should be private.

@MariaSolOs Thanks for pointing this out, I hadn't noticed that `vim.lsp.codelens.clear` also uses this function. But in my opinion, if the functions have the same name (even if they are...

> the preferred convention for bufnr/winnr/etc is: > > nil means "all" > 0 means "current" If it needs to be implemented in this way, it will be convenient for...