This adds the ability for Zed to restore unsaved buffers on restart. The
user is no longer prompted to save/discard/cancel when trying to close a
Zed window with dirty buffers in it. Instead those dirty buffers are
stored and restored on restart.
It does this by saving the contents of dirty buffers to the internal
SQLite database in which Zed stores other data too. On restart, if there
are dirty buffers in the database, they are restored.
On certain events (buffer changed, file saved, ...) Zed will serialize
these buffers, throttled to a 100ms, so that we don't overload the
machine by saving on every keystroke. When Zed quits, it waits until all
the buffers are serialized.
### Current limitations
- It does not persist undo-history (right now we don't persist/restore
undo-history regardless of dirty buffers or not)
- It does not restore buffers in windows without projects/worktrees.
Example: if you open a new window with `cmd-shift-n` and type something
in a buffer, this will _not_ be stored and you will be asked whether to
save/discard on quit. In the future, we want to fix this by also
restoring windows without projects/worktrees.
### Demo
https://github.com/user-attachments/assets/45c63237-8848-471f-8575-ac05496bba19
### Related tickets
I'm unsure about closing them, without also fixing the 2nd limitation:
restoring of worktree-less windows. So let's wait until that.
- https://github.com/zed-industries/zed/issues/4985
- https://github.com/zed-industries/zed/issues/4683
### Note on performance
- Serializing editing buffer (asynchronously on background thread) with
500k lines takes ~200ms on M3 Max. That's an extreme case and that
performance seems acceptable.
Release Notes:
- Added automatic restoring of unsaved buffers. Zed can now be closed
even if there are unsaved changes in buffers. One current limitation is
that this only works when having projects open, not single files or
empty windows with unsaved buffers. The feature can be turned off by
setting `{"session": {"restore_unsaved_buffers": false}}`.
---------
Co-authored-by: Bennet <bennet@zed.dev>
Co-authored-by: Antonio <antonio@zed.dev>
This PR updates the `cli: install` message for Linux. It initially threw
me off thinking that because `path_for_auxiliary_executable` is not
implemented for Linux it's failing and I thought it's a bug. Turns out
the CLI gets installed by the package manager and it's just named
something else.
I ended up only updating the message so it's more clear. If you don't
like the message, let me know :)
The old message:
The new message:
@ConradIrwin thank you for taking the time and explaining it to me.
closes: #14118
Release Notes:
- N/A
Closes#14146. This is just for the time being before a networking
refactoring to split reads and writes on the ROUTER/DEALER ZeroMQ
sockets. Some kernels have not been responding with `kernel_info_reply`,
which ends up hanging our shell socket.
Release Notes:
- N/A
Release notes for the REPL feature will be part of its official launch.
Allows Zed to open custom `zed://` links (redirects from
https://zed.dev/channels) on Linux used XDG MIME types.
This PR also allows the CLI to be able to open Zed (`zed://`) URIs
directly instead of executing the main executable in
`/usr/libexec/zed-editor`.
Release Notes:
- Linux: Allow `zed.dev/channel` (`zed://`) URIs to open on Linux
- CLI: Ability to open URIs from the command line
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This PR fixes the exact extension filtering introduced in #14588.
As we traversed the extensions we were always updating `exact_match`,
regardless of whether it matched the extension ID from the filter.
Release Notes:
- N/A
Release Notes:
- remoting: An alpha version of remote development is now available to
everyone. For more information on how to use it, and limitations see
https://zed.dev/docs/remote-development.
This PR adds some telemetry when the "View docs" button is clicked on a
feature upsell.
The goal here is to get a sense for how effective these upsells are at
getting users to click through if they can't find what they're looking
for.
Release Notes:
- N/A
In #14567 I claimed that the underlying allocation is reused. And it
was. At the time I've submitted a PR I was using `.filter_map(|x| x)`,
which got flagged by clippy as something that could be simplified to
`.flatten()` - that however broke the allocation reuse promise.
Thus, this PR goes back to using `filter_map` and additionally in debug
builds it performs checks for allocation reuse. With .flatten in place,
a bunch of unit test fail on that branch, so the checks do work.
Release Notes:
- N/A
# Background
In https://github.com/zed-industries/zed/issues/14408 we received a
repro for "Replace all" being slow, even after the work I did
https://github.com/zed-industries/zed/pull/13654. Admittedly #13654 was
a pretty straightforward change.
Under the profiler it turned out that we're spending *10 seconds* in
`memmove` on main thread. Ugh. Not great. The direct ancestor of the
memmove call was
66f0c390a8/crates/editor/src/display_map/tab_map.rs (L108-L119)
What?
# Accidental O(n^2)
We have a bunch of `consolidate_*_edits` functions which take a list of
Fold/Tab/Inlay/Wrap edits and merge consecutive edits if their ranges
overlap/are next to one another. The loop usually goes as follows:
```
while ix < edits.len() {
let (prev_edits, next_edits) = edits.split_at_mut(ix);
let prev_edit = prev_edits.last_mut().unwrap();
let edit = &next_edits[0];
if PREV_EDIT_CAN_BE_MERGED_WITH_CURRENT_ONE {
MERGE_EDITS(prev_edit, edit);
edits.remove(ix); // !!
} else {
ix += 1;
}
}
```
The problem is the call to `.remove` - it has to shift all of the
consecutive elements in the `edits` vector! Thus, when processing the
edits from the original repro (where consolidation shrinks the edit list
from 210k entries to 30k), we mostly spend time moving entries in memory
around.
Thus, the original repro isn't really an issue with replace_all; it's
just that replace_all is one of the few tools available to the end user
that can apply large # of edits in a single transaction.
# Solution
In this PR I address the issue by rewriting the loop in a way that does
not throw items away via `.remove`. Instead, `Iterator::scan` is used,
which lets us achieve the same logic without having the pitfalls of
`.remove`s.
Crucially, **this code does not allocate a new backing buffer for
edits** (see [this article for
rationale](https://blog.polybdenum.com/2024/01/17/identifying-the-collect-vec-memory-leak-footgun.html));
with `vec.into_iter().scan().filter_map().collect()` we still use the
same underlying buffer as the one that's passed into `consolidate_*`
functions. In development I verified that by checking whether the
pointers to backing storage of a Vec are the same before and after the
consolidation.
# Results
### Before
Nightly 0.145.0
[66f0c390a8](66f0c390a8)
https://github.com/user-attachments/assets/8b0ad3bc-86d6-4f8a-850c-ebb86e8b3bfc
(~13s end-to-end)
### After
https://github.com/user-attachments/assets/366835db-1d84-4f95-8c74-b1506a9fabec
(~2s end-to-end)
The remaining lag is (I think) lies in `TextSummary` calculation and not
the consolidation itself. Thus, for the purposes of scoping this PR,
I'll tackle it separately.
Release Notes:
- Significantly improved performance of applying large quantities of
concurrent edits (e.g. when running "Replace all").
Felt the link we were using for menu items that open a browser page was
not the best. That one is most typically used for attachments within
scope, as opposed to opening external links. Noticed that via the
"Copilot Settings" menu, which also felt like it could have a bit more
descriptive label. Also reduced the size of the rendered icon in this
component.
---
Release Notes:
- N/A
Release Notes:
- linux: Added a fallback Open picker for when XDG is not working
- Added a new setting `use_system_path_prompts` (default true) that can
be disabled to use Zed's builtin keyboard-driven prompts.
---------
Co-authored-by: Max <max@zed.dev>
This PR extends the extensions page with support for upselling built-in
Zed features when certain keywords are searched for.
This should help inform users about features that Zed has out-of-the-box
when they go looking for them as extensions.
For example, when someone searches "vim":
<img width="1341" alt="Screenshot 2024-07-15 at 4 58 44 PM"
src="https://github.com/user-attachments/assets/b256d07a-559a-43c2-b491-3eca5bff436e">
Here are more examples of what the upsells can look like:
<img width="1341" alt="Screenshot 2024-07-15 at 4 54 39 PM"
src="https://github.com/user-attachments/assets/1f453132-ac14-4884-afc4-7c12db47ad1d">
Release Notes:
- Added banners for built-in Zed features when corresponding keywords
are used in the extension search.
Provide a current, broken state as an experimental way to browse
diagnostics.
The diagnostics are grouped by lines and reduced into a block that, in
case of multiple diagnostics per line, could be toggled back and forth
to show more diagnostics on the line.
Use `grouped_diagnostics::Deploy` to show the panel.
Issues remaining:
* panic on warnings toggle due to incorrect excerpt manipulation
* badly styled blocks
* no key bindings to navigate between blocks and toggle them
* overall odd usability gains for certain groups of people
Due to all above, the thing is feature-gated and not exposed to regular
people.
Release Notes:
- N/A
TODO:
- [x] Actions run from menu not firing
- [x] Menu differentiates idle and busy for running kernel
Menu States:
- [x] No session && no support known
No session && no kernel installed for languages of known support
- (TODO after) Intro to REPL
- [x] Link to docs
No session but can start one
- [x] Start REPL
- (TODO after) More info -> Docs?
Yes Session
- [x] Info: Kernel name, language
example: chatlab-3.7-adsf87fsa (Python)
example: condapy-3.7 (Python)
- [x] Change Kernel -> https://zed.dev/docs/repl#change-kernel
- ---
- [x] Run
- [x] Interrupt
- [x] Clear Outputs
- ---
- [x] Shutdown
(Release notes left empty as the change will be documented in the REPL
release!)
Reserved for a follow on PR:
```
- [ ] Status should update when the menu is open (missing `cx.notify`?)
- [ ] Shutdown all kernels action
- [ ] Restart action
- [ ] [Default kernel changed - restart (this kernel) to apply] // todo!(kyle): need some kind of state thing that says if this has happened
```
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
Co-authored-by: Kyle Kelley <rgbkrk@gmail.com>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Release Notes:
- Added support for following into the assistant panel.
---------
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Nathan <nathan@zed.dev>
