Piotr Osiewicz 7eeb37262a assistant: Fix nested slash command rendering (#16173)
/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
2024-08-13 20:50:51 +02:00
2024-05-15 11:06:05 -06:00
2024-08-13 14:40:27 +03:00
2024-08-12 22:11:36 -04:00
2024-07-09 16:27:55 -04:00
2024-07-01 19:04:58 -04:00
2024-06-25 10:58:11 -04:00
WIP
2023-12-14 09:25:14 -07:00
2024-07-09 09:21:42 +02:00
2024-07-09 09:21:42 +02:00
2024-08-08 17:21:38 -07:00
2024-07-09 14:05:29 -07:00

Zed

CI

Welcome to Zed, a high-performance, multiplayer code editor from the creators of Atom and Tree-sitter.


Installation

Packaging status

On macOS and Linux you can download Zed directly or install Zed via your local package manager.

Other platforms are not yet available:

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 specified error for a crate you've created? If so, add publish = false under [package] in your crate's Cargo.toml.
  • Is the error failed to satisfy license requirements for 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 the accepted array in script/licenses/zed-licenses.toml.
  • Is cargo-about unable to find the license for a dependency? If so, add a clarification field at the end of script/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%