# lsp: Add \`detail\` to completion resolvable properties \(\#45985\) · gitcafe/zed

[View on GitCafe](https://git.cafe/gitcafe/zed/commit/8829f1d1d0d08a186f82c1ba98e55f50bca20563)

Repository: [gitcafe/zed](https://git.cafe/gitcafe/zed)

Visibility: public

Requested revision: 8829f1d1d0d08a186f82c1ba98e55f50bca20563

Requested commit: 8829f1d1d0d08a186f82c1ba98e55f50bca20563

Commit: 8829f1d1d0d08a186f82c1ba98e55f50bca20563

Tree: 5a5a9fce8f81ccf32e5e9e154b426fa1d7d1977d

Author: Shuhei Kadowaki

Committer: GitHub

## Message

```
lsp: Add `detail` to completion resolvable properties (#45985)

Previously, `detail` was not included in resolvable properties, which
prevented LSP-compliant servers from lazily resolving it.

In relation to this, I also investigated vtsls issues:
- https://github.com/yioneko/vtsls/issues/213
- https://github.com/zed-industries/zed/pull/21521

My conclusion is that regardless of whether Zed registers `detail` in
resolvable properties, vtsls always lazily resolves `detail`. However, I
understand that Zed's `resolve_completions` has been improved to handle
such "misbehaving" servers gracefully already, so I expect that adding
`detail` to resolvable properties will not cause any issues.

In fact, since Zed can lazy update all properties of completion items,
it might be appropriate to include all properties as resolvable except
for `label` (which is explicitly tested for consistency) and `data`
(which is used for resolution itself once).
However, since I'm uncertain if this is entirely correct, this commit
only adds `detail` to resolvable properties, as it was required to be
supported by LSP clients up to version 3.16.

Closes #ISSUE

Release Notes:

- N/A
```

## Parents

- [07f9d9d9805e2527a792378cdf717e0ce263b935](https://git.cafe/gitcafe/zed/commit/07f9d9d9805e2527a792378cdf717e0ce263b935?format=markdown)

[Source at this commit](https://git.cafe/gitcafe/zed/tree/8829f1d1d0d08a186f82c1ba98e55f50bca20563?format=markdown)