Co-Authored-By: Mikayla <mikayla@zed.dev>
Co-Authored-By: Nate <nate@zed.dev>
Closes#15606Closes#13515
Release Notes:
- Fixes `-` being considered a word character for selections in some
languages
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Nate <nate@zed.dev>
This PR updates the Assistant with support for receiving tool uses from
Anthropic models and capturing them as text in the context editor.
This is just laying the foundation for tool use. We don't yet fulfill
the tool uses yet, or define any tools for the model to use.
Here's an example of what it looks like using the example `get_weather`
tool from the Anthropic docs:
<img width="644" alt="Screenshot 2024-08-30 at 1 51 13 PM"
src="https://github.com/user-attachments/assets/3614f953-0689-423c-8955-b146729ea638">
Release Notes:
- N/A
This PR removes the `cache_control` field from the variants in
`ResponseContent`.
This field is used on requests to control the caching behavior, but is
not needed on content in the response.
Release Notes:
- N/A
This PR splits the `Content` type for Anthropic into two new types:
`RequestContent` and `ResponseContent`.
As I was going through the Anthropic API docs it seems that there are
different types of content that can be sent in requests vs what can be
returned in responses.
Using a separate type for each case tells the story a bit better and
makes it easier to understand, IMO.
Release Notes:
- N/A
I have found an error running tests in Golang projects that use
submodules. This PR fixes the issue by accessing the directory before
running the test.
The `commons` in the image is a git submodule in a subfolder inside a
parent folder where the workspace is set.
Release Notes:
- Fixed Go tests not being able to run in case the package (and the
`go.mod`) was in a nested folder. Pre-defined Go tasks have been changed
to now run in the package's directory. That means `go test ./package
-run MyTest` will run in `./package` and execute `go test -run MyTest`.
Also, `go test ./...` will run in the package directory, not at the root
of the Zed project, which is a small breaking change. In case one wants
to run `go test ./...` from the root, one can spawn a manual task that
does this.
---------
Co-authored-by: Thorsten Ball <mrnugget@gmail.com>
Fixes this weird behavior:
- open an file, like `test.rs`
- `ctrl-n` create an new buffer
- `ctrl-s` save new buffer with name `test.rs`, select replace old file.
- the older open file also exist, this is weird.
Release Notes:
- Fixed two panes staying opening when saving a new buffer with the same filename as a file that was already open.
This fixes a bug that I've been running into for quite a while:
- Open a new terminal inside Zed
- (Center pane loses focus)
- (Workspace is serialized)
- Quit Zed
- Open Zed
- (Workspace is deserialized without an active pane)
- Put cursor in assistant panel
- Try to use `ActivatePaneInDirection` to go to the center
- Does not work
So what this fix does is to ensure that in case the pane does become
focused, even though it was already marked as focused, the active center
pane is set.
It also adds a fallback when trying to get the last active pane.
Release Notes:
- Fixed an issue where `workspace::ActivatePaneInDirection` could not
activate the center pane (i.e. one couldn't navigate from terminal or
assistant panel to the center pane) after loading Zed.
This reverts commit 9206561662.
It lead to this panic:
```
Thread "main" panicked with "invalid SecondaryMap key used" at /Users/thorstenball/work/zed/crates/gpui/src/app/entity_map.rs:120:22
0: backtrace::backtrace::libunwind::trace
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/backtrace/libunwind.rs:116:5
backtrace::backtrace::trace_unsynchronized::<<backtrace::capture::Backtrace>::create::{closure#0}>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/backtrace/mod.rs:66:5
1: backtrace::backtrace::trace::<<backtrace::capture::Backtrace>::create::{closure#0}>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/backtrace/mod.rs:53:14
2: <backtrace::capture::Backtrace>::create
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/capture.rs:197:9
3: <backtrace::capture::Backtrace>::new
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/backtrace-0.3.73/src/capture.rs:162:22
4: zed::reliability::init_panic_hook::{closure#0}
at /Users/thorstenball/work/zed/crates/zed/src/reliability.rs:58:29
5: <alloc::boxed::Box<F,A> as core::ops::function::Fn<Args>>::call
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/alloc/src/boxed.rs:2077:9
std::panicking::rust_panic_with_hook
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:799:13
6: std::panicking::begin_panic::<&str>::{closure#0}
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:694:9
7: std::sys_common::backtrace::__rust_end_short_backtrace::<std::panicking::begin_panic<&str>::{closure#0}, !>
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/sys_common/backtrace.rs:171:18
8: std::panicking::begin_panic::<&str>
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:693:12
9: <slotmap::secondary::SecondaryMap<gpui::app::entity_map::EntityId, alloc::boxed::Box<dyn core::any::Any>> as core::ops::index::Index<gpui::app::entity_map::EntityId>>::index
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/slotmap-1.0.7/src/secondary.rs:866:21
10: <gpui::app::entity_map::EntityMap>::read::<vim::Vim>
at /Users/thorstenball/work/zed/crates/gpui/src/app/entity_map.rs:120:22
11: <gpui::app::entity_map::Model<vim::Vim>>::read
at /Users/thorstenball/work/zed/crates/gpui/src/app/entity_map.rs:397:9
12: <gpui::view::View<vim::Vim>>::read
at /Users/thorstenball/work/zed/crates/gpui/src/view.rs:81:9
13: <vim::VimAddon as editor::Addon>::should_show_inline_completions
at /Users/thorstenball/work/zed/crates/vim/src/vim.rs:138:20
14: <editor::Editor>::should_show_inline_completions
at /Users/thorstenball/work/zed/crates/editor/src/editor.rs:2347:21
15: <editor::Editor>::refresh_inline_completion
at /Users/thorstenball/work/zed/crates/editor/src/editor.rs:4988:17
16: <editor::Editor>::undo
at /Users/thorstenball/work/zed/crates/editor/src/editor.rs:6868:13
17: vim::normal::register::{closure#7}::{closure#0}
at /Users/thorstenball/work/zed/crates/vim/src/normal.rs:176:17
18: <vim::Vim>::update_editor::<(), vim::normal::register::{closure#7}::{closure#0}>::{closure#0}
at /Users/thorstenball/work/zed/crates/vim/src/vim.rs:693:45
19: <gpui:🪟:WindowContext as gpui::VisualContext>::update_view::<editor::Editor, (), <vim::Vim>::update_editor<(), vim::normal::register::{closure#7}::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:3890:22
20: <gpui:🪟:ViewContext<vim::Vim> as gpui::VisualContext>::update_view::<editor::Editor, (), <vim::Vim>::update_editor<(), vim::normal::register::{closure#7}::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:4522:9
21: <gpui::view::View<editor::Editor>>::update::<gpui:🪟:ViewContext<vim::Vim>, (), <vim::Vim>::update_editor<(), vim::normal::register::{closure#7}::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/view.rs:76:9
22: <vim::Vim>::update_editor::<(), vim::normal::register::{closure#7}::{closure#0}>
at /Users/thorstenball/work/zed/crates/vim/src/vim.rs:693:14
23: vim::normal::register::{closure#7}
at /Users/thorstenball/work/zed/crates/vim/src/normal.rs:174:9
24: <gpui:🪟:ViewContext<vim::Vim>>::listener::<vim::normal::Undo, vim::normal::register::{closure#7}>::{closure#0}::{closure#0}
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:4444:40
25: <gpui:🪟:WindowContext as gpui::VisualContext>::update_view::<vim::Vim, (), <gpui:🪟:ViewContext<vim::Vim>>::listener<vim::normal::Undo, vim::normal::register::{closure#7}>::{closure#0}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:3890:22
26: <gpui::view::View<vim::Vim>>::update::<gpui:🪟:WindowContext, (), <gpui:🪟:ViewContext<vim::Vim>>::listener<vim::normal::Undo, vim::normal::register::{closure#7}>::{closure#0}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/view.rs:76:9
27: <gpui::view::WeakView<vim::Vim>>::update::<gpui:🪟:WindowContext, (), <gpui:🪟:ViewContext<vim::Vim>>::listener<vim::normal::Undo, vim::normal::register::{closure#7}>::{closure#0}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/view.rs:192:12
28: <gpui:🪟:ViewContext<vim::Vim>>::listener::<vim::normal::Undo, vim::normal::register::{closure#7}>::{closure#0}
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:4444:13
29: <editor::Editor>::register_action::<vim::normal::Undo, <gpui:🪟:ViewContext<vim::Vim>>::listener<vim::normal::Undo, vim::normal::register::{closure#7}>::{closure#0}>::{closure#0}::{closure#0}
at /Users/thorstenball/work/zed/crates/editor/src/editor.rs:12053:25
30: <gpui:🪟:WindowContext>::dispatch_action_on_node
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:3514:21
31: <gpui:🪟:WindowContext>::dispatch_key_event
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:3303:13
32: <gpui:🪟:WindowContext>::dispatch_event
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:3131:13
33: <gpui:🪟:Window>:🆕:{closure#10}::{closure#0}
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:776:46
34: <gpui::app::AppContext as gpui::Context>::update_window::<gpui:🪟:DispatchEventResult, <gpui:🪟:Window>:🆕:{closure#10}::{closure#0}>::{closure#0}
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:1396:26
35: <gpui::app::AppContext>::update::<core::result::Result<gpui:🪟:DispatchEventResult, anyhow::Error>, <gpui::app::AppContext as gpui::Context>::update_window<gpui:🪟:DispatchEventResult, <gpui:🪟:Window>:🆕:{closure#10}::{closure#0}>::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:362:22
36: <gpui::app::AppContext as gpui::Context>::update_window::<gpui:🪟:DispatchEventResult, <gpui:🪟:Window>:🆕:{closure#10}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:1387:9
37: <gpui::app::async_context::AsyncAppContext as gpui::Context>::update_window::<gpui:🪟:DispatchEventResult, <gpui:🪟:Window>:🆕:{closure#10}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/app/async_context.rs:91:9
38: <gpui:🪟:AnyWindowHandle>::update::<gpui::app::async_context::AsyncAppContext, gpui:🪟:DispatchEventResult, <gpui:🪟:Window>:🆕:{closure#10}::{closure#0}>
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:4750:9
39: <gpui:🪟:Window>:🆕:{closure#10}
at /Users/thorstenball/work/zed/crates/gpui/src/window.rs:775:17
40: <alloc::boxed::Box<dyn core::ops::function::FnMut<(gpui::interactive::PlatformInput,), Output = gpui:🪟:DispatchEventResult>> as core::ops::function::FnMut<(gpui::interactive::PlatformInput,)>>::call_mut
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/alloc/src/boxed.rs:2070:9
41: gpui::platform::mac:🪟:handle_key_event
at /Users/thorstenball/work/zed/crates/gpui/src/platform/mac/window.rs:1300:32
42: gpui::platform::mac:🪟:handle_key_down
at /Users/thorstenball/work/zed/crates/gpui/src/platform/mac/window.rs:1212:5
43: <unknown>
44: <unknown>
45: <unknown>
46: <unknown>
47: <unknown>
48: <() as objc::message::MessageArguments>::invoke::<()>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc-0.2.7/src/message/mod.rs:128:17
49: objc::message::platform::send_unverified::<objc::runtime::Object, (), ()>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc-0.2.7/src/message/apple/mod.rs:27:9
50: objc::message::send_message::<objc::runtime::Object, (), ()>
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/objc-0.2.7/src/message/mod.rs:178:5
<*mut objc::runtime::Object as cocoa::appkit::NSApplication>::run
at /Users/thorstenball/.cargo/registry/src/index.crates.io-6f17d22bba15001f/cocoa-0.26.0/src/appkit.rs:628:9
51: <gpui::platform::mac::platform::MacPlatform as gpui::platform::Platform>::run
at /Users/thorstenball/work/zed/crates/gpui/src/platform/mac/platform.rs:427:13
52: <gpui::app::App>::run::<zed::main::{closure#3}>
at /Users/thorstenball/work/zed/crates/gpui/src/app.rs:159:9
53: zed::main
at /Users/thorstenball/work/zed/crates/zed/src/main.rs:439:5
54: <fn() as core::ops::function::FnOnce<()>>::call_once
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/ops/function.rs:250:5
55: std::sys_common::backtrace::__rust_begin_short_backtrace::<fn(), ()>
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/sys_common/backtrace.rs:155:18
56: std::rt::lang_start::<()>::{closure#0}
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/rt.rs:159:18
57: core::ops::function::impls::<impl core::ops::function::FnOnce<A> for &F>::call_once
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/core/src/ops/function.rs:284:13
std::panicking::try::do_call
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:559:40
std::panicking::try
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:523:19
std::panic::catch_unwind
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panic.rs:149:14
std::rt::lang_start_internal::{{closure}}
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/rt.rs:141:48
std::panicking::try::do_call
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:559:40
std::panicking::try
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panicking.rs:523:19
std::panic::catch_unwind
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/panic.rs:149:14
std::rt::lang_start_internal
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/rt.rs:141:20
58: std::rt::lang_start::<()>
at /rustc/051478957371ee0084a7c0913941d2a8c4757bb9/library/std/src/rt.rs:158:17
59: _main
```
Release Notes:
- N/A
This fixes an annoying bug I ran into, where supermaven completions
would show up in normal mode.
cc @ConradIrwin not sure if this is the best way to fix this, but it
seems like the neatest? On one hand, I didn't want to touch into Vim
from the editor, and on the other I didn't want to add another boolean
on the editor that flips on when in normal mode. So instead I extended
the Addon interface.
Release Notes:
- Fixed inline completions (Copilot or Supermaven) showing up in Vim's
normal mode.
Context servers might return CR characters, which are not acceptable in
Zed and cause ranges to be invalidated. We need to normalize them.
Closes#17109
Release Notes:
- context_servers: Fixed an issue where context servers returning a
carriage return character would result in a panic.
This PR adds support for completions via MCP. The protocol now supports
a new request type "completion/complete"
that can either complete a resource URI template (which we currently
don't use in Zed), or a prompt argument.
We use this to add autocompletion to our context server slash commands!
https://github.com/user-attachments/assets/08c9cf04-cbeb-49a7-903f-5049fb3b3d9f
Release Notes:
- context_servers: Added support for argument completions for context
server prompts. These show up as regular completions to slash commands.
This PR adds an initial set of default colors to `gpui`.
These will power default-styled gpui components (things like checkboxes,
buttons, inputs, etc.), storybook, and give a very simple,
appearance-aware set of colors out of the box for folks to build with.
These colors will evolve and be updated in the near future, they are
literally pulled from Finder for now :)
The API might not be perfect, I focused on getting something in quickly
that we can iterate on!
### Usage
```rs
use gpui::{colors, DefaultColor}
fn auto(cx: &WindowContext) -> {
// Init the full set of DefaultColors
let colors = colors(cx.appearance());
// Use a color
// It will automatically give you the correct color for the system's
// current appearance.
let background = DefaultColor::Background.hsla(&colors)
}
fn manual() -> {
// Init the full sets of DefaultColors
let light_colors = DefaultColors::light();
let dark_colors = DefaultColors::dark();
// Use a color
// Maybe for some fancy inverted element
let background = DefaultColor::Background.hsla(&light_colors)
let inverted_background = DefaultColor::Background.hsla(&dark_colors)
let inverted_text = DefaultColor::Text.hsla(&dark_colors)
}
```
Note: We need `cx` for the auto way as we need to get the system
appearance from the App/Window/ViewContext via `cx.appearance()`.
### Example
You can run `script/storybook default_colors` to open the Default Colors
story:
| Light | Dark |
|-------|------|
| 
| 
|
Release Notes:
- N/A
/cc @mrnugget
Release Notes:
- Fixed an issue where toggling inline completions in a markdown file
did not work correctly
---------
Co-authored-by: Marshall <marshall@zed.dev>
## Todo
* [x] Parse and present new XML output
* [x] Resolve new edits to buffers and anchor ranges
* [x] Surface resolution errors
* [x] Steps fail to resolve because language hasn't loaded yet
* [x] Treat empty `<symbol>` tag as None
* [x] duplicate assists when editing steps
* [x] step footer blocks can appear *below* the following message header
block
## Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Peter <peter@zed.dev>
Co-authored-by: Marshall <marshall@zed.dev>
Co-authored-by: Antonio <antonio@zed.dev>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
This changes the Zed CLI `zed` to pass along the environment to the Zed
project that it opens (if it opens a new one).
In projects, this CLI environment will now take precedence over any
environment that's acquired by running a login shell in a projects
folder.
The result is that `zed my/folder` now always behaves as if one would
run `zed --foreground` without any previous Zed version running.
Closes#7894Closes#16293
Related issues:
- It fixes the issue described in here:
https://github.com/zed-industries/zed/issues/4977#issuecomment-2305272027
Release Notes:
- Improved the Zed CLI `zed` to pass along the environment as it was on
the CLI to the opened Zed project. That environment is then used when
opening new terminals, spawning tasks, or language servers.
Specifically:
- If Zed was started via `zed my-folder`, a terminal spawned with
`workspace: new terminal` will inherit these environment variables that
existed on the CLI
- Specific language servers that allow looking up the language server
binary in the environments `$PATH` (such as `gopls`, `zls`,
`rust-analyzer` if configured, ...) will look up the language server
binary in the CLI environment too and use that environment when starting
the process.
- Language servers that are _not_ found in the CLI environment (or
configured to not be found in there), will be spawned with the CLI
environment in case that's set. That means users can do something like
`RA_LOG=info zed .` and it will be picked up the rust-analyzer that was
spawned.
Demo/explanation:
https://github.com/user-attachments/assets/455905cc-8b7c-4fc4-b98a-7e027d97cdfa
This PR attaches the `geoip_country_code` that we source from
Cloudflare's `CF-IPCountry` header to the HTTP request spans.
This will allow us to see where traffic is originating geographically.
Release Notes:
- N/A
- Cloudflare provides ISO-3166-1 country code for protectorates. Expand our allowlist to include the territories of countries on the allowlist (US, UK, France, Australia, New Zealand).
- Also include the country_code in the error message when we block.
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
- Remove "-" from word_character for CSS/JS/TSX/Markdown
- Makes our word-selection behavior consistent across language modes (and consistent with VSCode).
This test was flaky because both tasks were started at the same time and
the first one that would win, would navigate the editor.
Now the order is fixed, because the second task is only spawned after
the first one.
Release Notes:
- N/A
---------
Co-authored-by: Kirill <kirill@zed.dev>
Server can now include an optional description in a `prompts/get`
response. Zed will displayed the description as label of the slash
command.
Release Notes:
- context_servers: Servers can provide an optional description in
`prompts/get` responses that is displayed as the slash command label.
In the current `default.json`, `*_font_fallbacks=[]`, which results in
the `fallbacks` value in the `Font` struct always being `Some(...)`.
This PR introduces the following improvements:
1. Changed `*_font_fallbacks = []` to `*_font_fallbacks = null` in
`default.json`.
2. Enhanced the macOS and Windows implementations.
Release Notes:
- N/A
This PR contains the following updates:
| Package | Type | Update | Change |
|---|---|---|---|
| [cocoa](https://togithub.com/servo/core-foundation-rs) | dependencies
| minor | `0.25` -> `0.26` |
| [cocoa](https://togithub.com/servo/core-foundation-rs) |
workspace.dependencies | minor | `0.25` -> `0.26` |
---
### Configuration
📅 **Schedule**: Branch creation - "after 3pm on Wednesday" in timezone
America/New_York, Automerge - At any time (no schedule defined).
🚦 **Automerge**: Disabled by config. Please merge this manually once you
are satisfied.
♻ **Rebasing**: Whenever PR becomes conflicted, or you tick the
rebase/retry checkbox.
🔕 **Ignore**: Close this PR and you won't be reminded about these
updates again.
---
- [ ] <!-- rebase-check -->If you want to rebase/retry this PR, check
this box
---
Release Notes:
- N/A
<!--renovate-debug:eyJjcmVhdGVkSW5WZXIiOiIzOC41Ni4wIiwidXBkYXRlZEluVmVyIjoiMzguNTYuMCIsInRhcmdldEJyYW5jaCI6Im1haW4iLCJsYWJlbHMiOltdfQ==-->
---------
Co-authored-by: renovate[bot] <29139614+renovate[bot]@users.noreply.github.com>
Co-authored-by: Mikayla <mikayla@zed.dev>
Closes#6783
With this PR, the `journal: new journal entry` command only opens a new
workspace if the current workspace does not already contain the
`journal` directory. Both the root of the work tree and all its
subdirectories are checked.
This does not yet check for the day's file specifically, as suggested
[here](https://github.com/zed-industries/zed/issues/6783#issuecomment-2268509463).
I'm new to writing Rust code in production (as well as contributing in
general), so any feedback is much appreciated!
Release Notes:
- Reuse workspace on `journal: new journal entry` command if possible
Closes#10782
In some cases, during the auto-update process,
the update can fail and leave a dangling disk image in macOS. If the
auto-update fails again, a new dangling mounted volume will be left
behind. To avoid polluting the system with these dangling mounted disk
images,
implement [the `Drop`
trait](https://doc.rust-lang.org/std/ops/trait.Drop.html) for the
`MacOSUnmounter` struct. This will ensure that the disk image
is unmounted when the `install_release_macos` function exits regardless
of its result.
## How to test this locally
Unfortunately, I was a bit too lazy to find a smarter way to test this,
so I simply commented out a bunch of lines to emulate the auto-update
process. To replicate the linked issue (#10782), you can apply the
attached patch. Build the Zed binary and run it. The auto-update should
fail, leaving the dangling mounted disk image in the system:
```shell
>diskutil list
/dev/disk5 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +220.6 MB disk5
Physical Store disk4s1
1: APFS Volume Zed 190.6 MB disk5s1
```
Run the Zed binary again to create another mounted disk image:
```shell
>diskutil list
/dev/disk5 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +220.6 MB disk5
Physical Store disk4s1
1: APFS Volume Zed 190.6 MB disk5s1
/dev/disk7 (synthesized):
#: TYPE NAME SIZE IDENTIFIER
0: APFS Container Scheme - +220.6 MB disk7
Physical Store disk6s1
1: APFS Volume Zed 190.6 MB disk7s1
```
[simulate_zed_autoupdate.patch](https://github.com/user-attachments/files/16787955/simulate_zed_autoupdate.patch)
Please let me know if the fix is good; otherwise, I am happy to
implement it differently. Thanks!
Release Notes:
- Fixed#10782
Closes#12313
This PR introduces the following improvements:
1. Fixed the issue where the auto-hide taskbar wouldn't automatically
appear when Zed is maximized.
2. Refactored the `WM_NCCALCSIZE` code, making it more human-readable.
Release Notes:
- Fixed auto-hide taskbar would refuse to show itself when `Zed` is
maximized on
Winodws([#12313](https://github.com/zed-industries/zed/issues/12313)).
---------
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
when the focused_vim is deactivate, focused_vim should set none.
fix the problem that opening the first buffer from EmptyPane will not
toggle,The reason is the edge case where focused_vim is none when
opening for the first time.
Release Notes:
- N/A
At the moment Zed is handled as default file browser which causes
applications like RustRover to open Zed when instead it should open the
Gnome files app. And Zed is probably not intended to be an replacement
to the Gnome files app for example.
I'm also currently waiting to fix the issue that Zed is not displayed as
an "Application" when using "Open with..." on Arch Linux. Which is
caused by not setting `APP_ARGS` which should have the value `%F`
Release Notes:
- Fixed: Zed will no longer be handled as default file browser
This PR fixes two issues:
1. The prompt library window didn't set an `app_id` on Linux, which
caused it to be missing the Zed logo
2. A dangling reference to the window in the Wayland client code, which
caused the prompt library window not to close. See:
https://github.com/zed-industries/zed/pull/13201
Release Notes:
- Linux: Fixed the prompt library not closing on Wayland
---------
Co-authored-by: Junkui Zhang <364772080@qq.com>
