mirror of
https://github.com/zed-industries/zed.git
synced 2024-09-20 02:47:34 +03:00
Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
6f40da77b6
When the `List` element's state is `ListState::reset()`, it eagerly trashes it's cached element heights in anticipation of a prompt render. But, due to the recent `display_layer` changes, that re-render is not always forthcoming. This is a problem for `ListState::scroll()`, which depends on these cached elements to correctly calculate the new logical scroll offset. Solutions we attempted: - Cache the element heights and continue the scroll calculation - This was conceptually incorrect, reset should only be called when the underlying data has been changed, making any calculation with the old results meaningless. - Lazily re-compute the element heights in scroll - Beyond being a non-trivial refactor, this would probably also cause us to double-render the list in a single frame, which is bad. - Cache the scroll offset and only calculate it in paint - This solution felt awkward to implement and meant we can't supply synchronous list scroll events. - Delay resetting until paint - This means that all of the other APIs that `ListState` supplies would give temporarily incorrect results, worsening the problem Given these issues, we settled on the solution with the least compromises: drop scroll events if the state has been `reset()` between `paint()` and `scroll()`. This shifts the responsibility for the problem out of the List element and into consumers of `List`, if you want perfectly smooth scrolling then you need to use `reset()` judiciously and prefer `splice()`. That said, I tested this by aggressively scrolling the Collab panel, and it seems to work as well as it did before. This PR also includes some initial testing infrastructure for working with input from the platform and rendered elements. Release Notes: - N/A |
||
|---|---|---|
| .cargo | ||
| .config | ||
| .github | ||
| .vscode | ||
| .zed | ||
| assets | ||
| crates | ||
| docs | ||
| plugins | ||
| script | ||
| .dockerignore | ||
| .gitignore | ||
| .gitmodules | ||
| Cargo.lock | ||
| Cargo.toml | ||
| CONTRIBUTING.md | ||
| debug.plist | ||
| docker-compose.sql | ||
| docker-compose.yml | ||
| Dockerfile | ||
| Procfile | ||
| README.md | ||
| rust-toolchain.toml | ||
🚧 TODO 🚧
- Add intro
- Add link to contributing guide
- Add barebones running zed from source instructions
- Link out to further dev docs
Zed
Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Developing Zed
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.