We're finally doing the thing.
TODO:
- [x] Choose an approach
- Decided to add a new element just for the pane axis, containing a
slimmed down copy of the flex code.
- [x] Wire through callbacks and pointers so that data goes where it
needs to
- [x] Do the flex juggling math on resize
- [x] Update the flexes when updating the split tree
- [x] Restore the active_pane_magnification setting
- [x] Serialize an axis' flexes
Release Notes:
- Made the center pane group splits resizable. Note that resizing is
disabled if the `active_pane_magnification` setting is changed from
default.
Deals with https://github.com/zed-industries/community/issues/752
Deals with https://github.com/zed-industries/community/issues/566
Currently, when converting from LSP to Zed objects, completions with
non-empty `additional_text_edits` are filtered out.
Later, all other completions form a list and the selected one gets the
`Editor::confirm_completion` call, which always queries an LSP
completion resolve request to get the `additional_text_edits` field.
Otherwise, `additional_text_edits` field is ignored entirely for the
rest of the completion lifetime — and we always pass the selected
completion through the resolve request.
The PR changes the logic, removing the `additional_text_edits` filtering
and instead of resolving every completion, now we check for
`additional_text_edits` in the completion before resolving: resolve
happens only if the data is absent.
Generally, feels like resolve has to happen before the completion
selection: LSP servers may send us markdown for completion documentation
preview pop ups and similar extra info.
Also, the server may lack resolve capabilities entirely, always sending
the request seems dangerous.
For now, the PR does not attempt to change either.
Release Notes:
- Brings rust-analyzer's postfix completions and others completions with
preresolved additional text edits
This PR includes a new crate, aimed at maintaining a consistent semantic
embedding database, for any project opened with Zed. At a high level,
for each file in a project, we parse the file with treesitter, embed the
symbol "document" objects with OpenAI, and maintain a consistent
database of these embeddings and offset locations in a sqlite database.
Once stored, we have built a simple modal interface for querying on
these symbols embeddings using natural language, offering the
opportunity to navigate to the selected symbol.
This initial PR is intended to provide this functionality only in preview,
as we explore, evaluate and iterate on the vector store.
- Full task details are provided in the [Semantic Search Linear
Project](https://linear.app/zed-industries/project/semantic-search-7c787d198ebe/Z)
Kevin Hovsäter reported a crash in cli when running 'cargo run -p cli --
--bundle-path target/debug/Zed'. It was caused by unaligned pointer
access in ipc-channel library; rustc started generating debug_asserts
for pointer alignment starting with 1.70, which we have
oh-so-conveniently upgraded to shortly before Kevin noticed a crash.
Rust 1.70 did not introduce this panic, it merely started triggering on
UB that was previously ignored.
/cc @hovsater @SomeoneToIgnore
Release Notes:
- N/A
Kevin Hovsäter reported a crash in cli when running 'cargo run -po cli -- --bundle-path target/debug/Zed'. It was caused by unaligned pointer access in ipc-channel library; rustc started generating debug_asserts for pointer alignment starting with 1.70, which we have oh-so-conveniently upgraded to shortly before Kevin noticed a fix.
Rust 1.70 did not introduce this panic, it merely started triggering on UB that was previously ignored.
Match highlighting for recent projects picker was off, because the path
representation was compacted - for a path '/Users/hiro/Projects/zed' we
compact it to use a tilde instead of home directory. However, the
highlight positions were always calculated for a full path, leading to a
mismatch in highlights. This commit addresses this by running fuzzy
search on compacted paths instead of using long paths. This might lead
to a slight performance hit, but given that recent projects modal
shouldn't have that many items in the first place, it should be okay.
Z-2546
Release Notes:
- Fixed result highlighting in "Recent projects" modal.
Nate Butler