Previously, when scrolling the diagnostics view with the mouse, we'd get
a spurious horizontal scroll (even if the content was not overflowing
horizontally) due to an error in the widths of the diagnostic blocks.
Release Notes:
- Fixed an issue where the project diagnostics view spuriously allowed
horizontal scrolling by a small amount.
Just spotted a tiny error that was causing us to continue looking for
nested folds 1 layer deeper than any fold already found at the target
level. We shouldn't continue to seek for a deeper fold after the fold at
the target level is found.
Tested on a debug build and used `editor.rs` as the source material:
```
Old
Level 1 fold:
[crates/editor/src/editor.rs:10777:9] counter = 2806
[crates/editor/src/editor.rs:10778:9] time_elapsed = 320.570792ms
Level 2 fold:
[crates/editor/src/editor.rs:10777:9] counter = 5615
[crates/editor/src/editor.rs:10778:9] time_elapsed = 497.4305ms
Level 3 fold:
[crates/editor/src/editor.rs:10777:9] counter = 7528
[crates/editor/src/editor.rs:10778:9] time_elapsed = 619.818334ms
New
Level 1 fold:
[crates/editor/src/editor.rs:10776:9] counter = 543
[crates/editor/src/editor.rs:10777:9] time_elapsed = 139.115625ms
Level 2 fold:
[crates/editor/src/editor.rs:10776:9] counter = 2806
[crates/editor/src/editor.rs:10777:9] time_elapsed = 312.560416ms
Level 3 fold:
[crates/editor/src/editor.rs:10776:9] counter = 5615
[crates/editor/src/editor.rs:10777:9] time_elapsed = 498.873292ms
```
Release Notes:
- N/A
Closes#19372
Release Notes:
- Fixed autoclosing quotes when the string is already open.
- Added autoclosing of rust multiline strings
---------
Co-authored-by: Kurt Wolf <kurtwolfbuilds@gmail.com>
This PR adds the ability for editor blocks to replace lines of text, but
does not yet use that feature anywhere. We'll update assistant patches
to use replace blocks on another branch:
https://github.com/zed-industries/zed/tree/assistant-patch-replace-blocks
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Richard Feldman <richard@zed.dev>
Co-authored-by: Marshall Bowers <marshall@zed.dev>
Co-authored-by: Nathan Sobo <nathan@zed.dev>
This PR makes it so that when we apply changes within a branch
buffer—currently just the edits buffer—we save the underlying buffer.
This also fixes an issue where new files created via edits were not
properly flushed to disk.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
Closes https://github.com/zed-industries/zed/issues/8534
Supersedes https://github.com/zed-industries/zed/pull/16349
Potential concerns:
* we do not follow up to the `/` when looking for `.editorconfig`, only
up to the worktree root.
Seems fine for most of the cases, and the rest should be solved
generically later, as the same issue exists for settings.json
* `fn language` in `AllLanguageSettings` is very hot, called very
frequently during rendering. We accumulate and parse all `.editorconfig`
file contents beforehand, but have to go over globs and match these
against the path given + merge the properties still.
This does not seem to be very bad, but needs more testing and
potentially some extra caching.
Release Notes:
- Added .editorconfig support
---------
Co-authored-by: Ulysse Buonomo <buonomo.ulysse@gmail.com>
This simplifies rendering of excerpt headers and footers, and removes
the need to store a `BlockDisposition` on these boundary blocks. It's a
step toward implementing "replace blocks", which we want to use in the
assistant panel.
We've also cleaned up the way heights are specified for headers and
footers and fixed some visual asymmetries between the "expand upward"
and "expand downward" buttons.
Release Notes:
- N/A
---------
Co-authored-by: Richard <richard@zed.dev>
This changes the `/workflow` command so that instead of emitting edits
in separate steps, the user is presented with a single tab, with an
editable diff that they can apply to the buffer.
Todo
* Assistant panel
* [x] Show a patch title and a list of changed files in a block
decoration
* [x] Don't store resolved patches as state on Context. Resolve on
demand.
* [ ] Better presentation of patches in the panel
* [ ] Show a spinner while patch is streaming in
* Patches
* [x] Preserve leading whitespace in new text, auto-indent insertions
* [x] Ensure patch title is very short, to fit better in tab
* [x] Improve patch location resolution, prefer skipping whitespace over
skipping `}`
* [x] Ensure patch edits are auto-indented properly
* [ ] Apply `Update` edits via a diff between the old and new text, to
get fine-grained edits.
* Proposed changes editor
* [x] Show patch title in the tab
* [x] Add a toolbar with an "Apply all" button
* [x] Make `open excerpts` open the corresponding location in the base
buffer (https://github.com/zed-industries/zed/pull/18591)
* [x] Add an apply button above every hunk
(https://github.com/zed-industries/zed/pull/18592)
* [x] Expand all diff hunks by default
(https://github.com/zed-industries/zed/pull/18598)
* [x] Fix https://github.com/zed-industries/zed/issues/18589
* [x] Syntax highlighting doesn't work until the buffer is edited
(https://github.com/zed-industries/zed/pull/18648)
* [x] Disable LSP interaction in Proposed Changes editor
(https://github.com/zed-industries/zed/pull/18945)
* [x] No auto-indent? (https://github.com/zed-industries/zed/pull/18984)
* Prompt
* [ ] make sure old_text is unique
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Richard <richard@zed.dev>
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
* uses the state that's synced, to fetch the language server name
* uses proper, canonicalized path when creating a remote ssh worktree,
otherwise `~/foo/something` stays unexpanded
Release Notes:
- N/A
Release Notes:
- Added a new `editor: format selections` action that allows formatting
only the currently selected text via the primary language server.
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
TL;DR: Another O(n^2) strikes.
In #19194 we received a report about a 7Mb JSON file that Zed struggles
with. Naturally this file showcased a O(n^2) in line layout; this file
has one long line.
During line layout for Mac we have to convert between UTF-16 and UTF-8
indices in the string, as CoreText works with UTF-16 and Rust strings
are UTF-8. The problem stemmed from the fact that we were re-seeking our
string converter on each glyph, which boils down to: we were reparsing
[0..curr_string_position] bytes up to full length of the string, which
is the O(n^2) in question. This PR changes this behaviour to reuse the
Index Converter if the position we're seeking to is not yet reached.
Basically, we're treating the converter as forward iterator and we try
to seek with the same iterator, if possible.
Where previously you could not even open the file in OP (within
reasonable time frame, I waited for 40 seconds before giving up), now
you can do it in.. slightly over a second. The best part is: the
experience is still not ideal. Typing in the buffer is sluggish. Still,
this is a start.
Release Notes:
- Mac: Improved performance with very long lines
* `Open Excerpts` command always opens the locations in the base buffer
* LSP features like document-highlights, go-to-def, and inlay hints work
correctly in branch buffers
* Other LSP features like completions, code actions, and rename are
disabled in branch buffers
Release Notes:
- N/A
Reworks the way tasks are stored, accessed and synchronized in the
`project`.
Now both collab and ssh remote projects use the same TaskStorage kind to
get the task context from the remote host, and worktree task templates
are synchronized along with other worktree settings.
Release Notes:
- Adds ssh support to tasks, improves collab-remote projects' tasks sync
After https://github.com/rust-lang/rust-analyzer/pull/18167 and certain
people who type and complete rapidly, it turned out that we have not
waited for `completionItem/resolve` to finish before applying the
completion results.
Release Notes:
- Fixed completion items applied improperly on fast typing
This PR qualifies a call to `RangeExt::overlaps` to avoid some confusion
in rust-analyzer not being able to distinguish between
`RangeExt::overlaps` and `AnchorRangeExt::overlaps` and producing
phantom diagnostics.
We may also want to consider renaming the method on `AnchorRangeExt` to
disambiguate them.
Release Notes:
- N/A
This PR updates the color swatches added in #18665 to use a predefined
`rounding` value instead of a literal value.
The underlying values are the same, but we don't want to diverge from
our design system.
Release Notes:
- N/A
Closes#11991
Release Notes:
- Added support for color swatches for language server completions.
<img width="502" alt="Screenshot 2024-10-02 at 19 02 22"
src="https://github.com/user-attachments/assets/57e85492-3760-461a-9b17-a846dc40576b">
<img width="534" alt="Screenshot 2024-10-02 at 19 02 48"
src="https://github.com/user-attachments/assets/713ac41c-16f0-4ad3-9103-d2c9b3fa8b2e">
This implementation is mostly a port of the VSCode version of the
ColorExtractor. It seems reasonable the we should support _at least_
what VSCode does for detecting color swatches from LSP completions.
This implementation could definitely be better perf-wise by writing a
dedicated color parser. I also think it would be neat if, in the future,
Zed handled _more_ color formats — especially wide-gamut colors.
There are a few differences to the regexes in the VSCode implementation
but mainly so simplify the implementation :
- The hex vs rgb/hsl regexes were split into two parts
- The rgb/hsl regexes allow 3 or 4 color components whether hsla/rgba or
not and the parsing implementation accepts/rejects colors as needed
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Additionally, mark context menu entry as disabled when the action would
fail (untitled buffer, collab sessions).
Supersedes #18584
Release Notes:
- Fixed "Reveal in Finder/File Manager", "Copy Path", "Copy Relative
Path" and "Copy file location" actions not working with multibuffers.
Also, fix visual bug when pressing escape with a non-empty selection in
a deleted text block.
Release Notes:
- N/A
Co-authored-by: Antonio <antonio@zed.dev>
I have just recently discovered this keybinding myself out of talking to
folks, ha. The tooltip here might ease the discovery for other folks in
the future.
<img width="700" alt="Screenshot 2024-09-27 at 11 04 28 PM"
src="https://github.com/user-attachments/assets/844d3b55-15af-47f7-a8db-5c8832ceba29">
---
Release Notes:
- N/A
Fixes https://github.com/zed-industries/zed/issues/18405
In https://github.com/zed-industries/zed/pull/18313, we introduced a
problem where git addition highlights might spuriously return when
undoing certain changes. It turned out, there were already some cases
where git hunk highlighting was incorrect when editing at the boundaries
of expanded diff hunks.
In this PR, I've introduced a test helper method for more rigorously
(and readably) testing the editor's git state. You can assert about the
entire state of an editor's diff decorations using a formatted diff:
```rust
cx.assert_diff_hunks(
r#"
- use some::mod1;
use some::mod2;
const A: u32 = 42;
- const B: u32 = 42;
const C: u32 = 42;
fn main() {
- println!("hello");
+ //println!("hello");
println!("world");
+ //
+ //
}
fn another() {
println!("another");
+ println!("another");
}
- fn another2() {
println!("another2");
}
"#
.unindent(),
);
```
This will assert about the editor's actual row highlights, not just the
editor's internal hunk-tracking state.
I rewrote all of our editor diff tests to use these more high-level
assertions, and it caught the new bug, as well as some pre-existing bugs
in the highlighting of added content.
The problem was how we *remove* highlighted rows. Previously, it relied
on supplying exactly the same range as one that we had previously
highlighted. I've added a `remove_highlighted_rows(ranges)` APIs which
is much simpler - it clears out any row ranges that intersect the given
ranges (which is all that we need for the Git diff use case).
Release Notes:
- N/A
Closes#6822
Updates #5142
Release Notes:
- Added new fold actions to toggle folds (`cmd-k cmd-l`), fold every
fold (`cmd-k cmd-0`) unfold every fold (`cmd-k cmd-j`) to fold
recursively (`cmd-k cmd-[`) and unfold recursively (`cmd-k cmd-]`).
- vim: Added `za` to toggle fold under cursor.
- vim: Added `zO`/`zC`/`zA` to open, close and toggle folds recursively
(and fixed `zc` to not recurse into selections).
- vim: Added `zR`/`zM` to open/close all folds in the buffer.
I was inspecting how Zed did the layout in the editor, specifically for
the gutter, and noticed that `em_width * X` is being used as the 'width
of X consecutive characters'. Howevever, that math didn't work for me,
because em_width doesn't account for the space between characters, so
you can't just multiply it by a character count.
One place this is actually noticeable is in the logic for
`min_width_for_number_on_gutter`, where we try to reserve 4 characters
of line number space. However, once you actually hit 4 characters, the
actual width is bigger, causing things to resize. This seems clearly
counter to the intent of the code.
It seems the more correct logic is to use `em_advance` which accounts
for the space between the characters. I am leaving the rest of the uses
of `em_width` for generic padding. It is also possible that
`column_pixels()` would be the more correct fix here, but it wasn't
straightforward to use that due to it residing EditorElement source
file.
On my MacBook this increases the width of the gutter by 6 pixels when
there are <999 lines in the file, otherwise it's identical.
It might be worth doing some more general audit of some of the other
uses of em_width as a concept. (e.g. `git_blame_entries_width`)
https://github.com/user-attachments/assets/f2a28cd5-9bb6-4109-bf41-1838e56a75f9
Release Notes:
- Fix a slight gutter flicker when going over 999 lines
Before this change, `use_on_type_format` would only have an effect when
defined on a global level in our settings.
But our default.json settings would also document that it's used in
language settings, i.e.:
```json
{
"languages": {
"C": {
"use_on_type_format": false
},
"C++": {
"use_on_type_format": false
}
}
}
```
But this did **not** work.
With the change, it now works globally and per-language.
Release Notes:
- Fixed `use_on_type_format` setting not working when defined inside
`"languages"` in the settings. This change will now change the default
behavior for C, C++, and Markdown, by turning language server's
`OnTypeFormatting` completions off by default.
Co-authored-by: Bennet <bennet@zed.dev>
Closes#18119
Release Notes:
- Fixed the cursor shape in the editor not changing back to default when
`{"cursor_shape": "..."}` setting is removed. (Does not apply to Vim
mode.)
This PR adds some more functionality to the Proposed Changes Editor
view, which we'll be using in
https://github.com/zed-industries/zed/pull/18240 for allowing the
assistant to propose changes to a set of buffers.
* Add an `Apply All` button, and fully implement applying of changes to
the base buffer
* Make the proposed changes editor searchable
* Fix a bug in branch buffers' diff state management
Release Notes:
- N/A
Todo:
* [x] Tooltips for hunk buttons
* [x] Buttons to go to next and previous hunk
* [x] Ellipsis button that opens a context menu with `Revert all`
/cc @iamnbutler @danilo-leal for design 👀
Release Notes:
- Changed the behavior of the git gutter so that diff hunk are expanded
immediately when clicking the gutter, and hunk controls are displayed
above the hunk.
---------
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
