c58ab57a05
Closes #37836 This behavior was already fixed for Supermaven in #37047, but is still present in Copilot. What's actually happening: - Receive a multi-line edit prediction - Dismiss it with escape - Clicking anywhere in the editor below the cursor calls `Editor::select` which starts out by calling `Editor::hide_context_menu` -> `Editor::update_visible_edit_prediction`, bringing back the prediction that was just dismissed and updating the editor's display map - The subsequent selection logic in `Editor::select` now operates using a display map that is inconsistent with what the user saw when clicking - If the click was anywhere where the prediction inlay used to be, `Editor::select` thinks the user clicked on the inlay and does nothing, and the inlay reappears - If the click was below where the prediction inlay used to be, the inlay is immediately removed again but the cursor is moved to the wrong position because the inlay temporarily added a vertical offset to all lines after it in the buffer Ultimately, `Editor::select` should be handling the user input using the same display map that the user saw when making the input. This can obviously be solved in multiple ways, I chose to clear the current completions in `CopilotCompletionProvider::discard` such that any subsequent calls to `Editor::update_visible_edit_prediction` doesn't immediately nullify the dismissal of the edit prediction by the user. Note that this also changes the behavior that occurs after dismissing an edit prediction, moving to a different position in the buffer, and then returning: currently, this resurfaces the dismissed edit prediction (which the `test_copilot` test exercises), and after this change it doesn’t. This current behavior didn't seem desirable to me because it doesn't happen when using Zeta or Supermaven, but if we want to keep it, then we could fix the incorrect selection behavior some other way. Release Notes: - Fixed bug that resurfaced dismissed Copilot edit predictions when moving the cursor around Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com> Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Installation
On macOS, Linux, and Windows you can download Zed directly or install Zed via your local package manager (macOS/Linux/Windows).
Other platforms are not yet available:
- Web (tracking issue)
Developing Zed
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.
Sponsorship
Zed is developed by Zed Industries, Inc., a for-profit company.
If you’d like to financially support the project, you can do so via GitHub Sponsors. Sponsorships go directly to Zed Industries and are used as general company revenue. There are no perks or entitlements associated with sponsorship.