Smit Barmase
4d79edc753
Closes #34094 Bug in https://github.com/zed-industries/zed/pull/11157 **Context:** In https://github.com/zed-industries/zed/pull/31872, we added logic to avoid re-querying language server completions (`textDocument/completion`) when possible. This means the list of `lsp::CompletionItem` objects we have might be stale and not contain accurate data like `text_edit`, which is only valid for the buffer at the initial position when these completions were requested. We don't really care about this because we already extract all the useful data we need (like insert/replace ranges) into `Completion`, which converts `text_edit` to anchors. This means further user edits simply push/move those anchors, and our insert/replace ranges persist for completion accept. ```jsonc // on initial textDocument/completion "textEdit":{"insert":{"start":{"line":2,"character":0},"end":{"line":2,"character":11}},"replace":{"start":{"line":2,"character":0},"end":{"line":2,"character":11}} ``` However, for showing documentation of visible `Completion` items, we need to call resolve (`completionItem/resolve`) with the existing `lsp::CompletionItem`, which returns the same `text_edit` and other existing data along with additional new data that was previously optional, like `documentation` and `detail`. **Problem:** This new data like `documentation` and `detail` doesn't really change on buffer edits for a given completion item, so we can use it. But `text_edit` from this resolved `lsp::CompletionItem` was valid when the the initial (`textDocument/completion`) was queried but now the underlying buffer is different. Hence, creating anchors from this ends up creating them in wrong places. ```jsonc // calling completionItem/resolve on cached lsp::CompletionItem results into same textEdit, despite buffer edits "textEdit":{"insert":{"start":{"line":2,"character":0},"end":{"line":2,"character":11}},"replace":{"start":{"line":2,"character":0},"end":{"line":2,"character":11}} ``` It looks like the only reason to override the new text and these ranges was to handle an edge case with `typescript-language-server`, as mentioned in the code comment. However, according to the LSP specification for [Completion Request](https://microsoft.github.io/language-server-protocol/specifications/lsp/3.17/specification/#textDocument_completion): > All other properties (usually sortText, filterText, insertText and textEdit) must be provided in the textDocument/completion response and **must not be changed during resolve.** If any language server responds with different `textEdit`, `insertText`, etc. in `completionItem/resolve` than in `textDocument/completion`, they should fix that. Bug in this case in `typescript-language-server`: https://github.com/typescript-language-server/typescript-language-server/pull/303#discussion_r869102064 We don't really need to override these at all. Keeping the existing Anchors results in correct replacement. Release Notes: - Fixed issue where in some cases there would be an extra `}` at the end of imports when accepting completions.
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS and Linux you can download Zed directly or install Zed via your local package manager.
Other platforms are not yet available:
- Windows (tracking issue)
- Web (tracking issue)
Developing Zed
- Building Zed for macOS
- Building Zed for Linux
- Building Zed for Windows
- Running Collaboration Locally
Contributing
See CONTRIBUTING.md for ways you can contribute to Zed.
Also... we're hiring! Check out our jobs page for open roles.
Licensing
License information for third party dependencies must be correctly provided for CI to pass.
We use cargo-about to automatically comply with open source licenses. If CI is failing, check the following:
- Is it showing a
no license specifiederror for a crate you've created? If so, addpublish = falseunder[package]in your crate's Cargo.toml. - Is the error
failed to satisfy license requirementsfor a dependency? If so, first determine what license the project has and whether this system is sufficient to comply with this license's requirements. If you're unsure, ask a lawyer. Once you've verified that this system is acceptable add the license's SPDX identifier to theacceptedarray inscript/licenses/zed-licenses.toml. - Is
cargo-aboutunable to find the license for a dependency? If so, add a clarification field at the end ofscript/licenses/zed-licenses.toml, as specified in the cargo-about book.