7eeb37262aa55b207c7df1266c8276b96457dbd3
/rant on We have this issue where if a prompt starts with a slash command (e.g. /workflow), the rendering is a bit messed up. The nested slash command gets picked up as the parent of a command that includes it (/prompt). This is due to how we parse slash commands; their output is obtained asynchronously. When we run `/prompt "My prompt"` whose contents are `/workflow`, we first include the prompt content verbatim and then reparse the whole buffer, picking up /workflow as a new command (as if it was typed by an user). The problem with that is that the range of parent /prompt does not include the expanded range of a /workflow; in fact, after doing full expansion of "My prompt", we lose track of the parent-children relationship of these two slash commands and treat them as if top-level user prompt was `/workflow/prompt "My prompt"` and not `/prompt "My prompt"` (which, by the way, would not be parsable for us). The "proper" fix would be to update the parent range whenever we parse a new children within it. We could do that. But then, the question is; what do we gain from it? Slash command output is put behind a crease, which is fundamentally a fold. Given "My prompt", we'd have to put two fold indicators on a single line even if the ranges were set up correctly. So that merely moves the target elsewhere into yet another issue. Even if we did solve two-fold problem somehow (by e.g. sorting same-line folds by the end point), we would still be stuck with suboptimal render. What do we gain from all that anyways? Proper handling of a relatively obscure (although - at the same time - quite common) edge case which may as well be handled by having /prompt insert a new line if there's a slight chance that the edge case could occur. And that hacky, "inproper" solution is what this PR does; in fact, it's not the first time it was done, as /default also has the same issue which it solves in precisely the same manner. /rant off Release Notes: - N/A
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.
Description
Code at the speed of thought – Zed is a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.
Readme
586 MiB
Languages
Rust
94.7%
JSON-with-Comments
3.1%
Inno Setup
0.6%
Scheme
0.5%
Shell
0.3%
Other
0.4%