I was trying to use Zed for Rust debugging on windows, but was getting
this warning in debugger console: "Could not initialize Python
interpreter - some features will be unavailable (e.g. debug
visualizers)."
As the warning suggests this led to bad debugging experience where the
variables were not visualized properly in the "Variables" panel.
After some investigation I found that the problem is that Zed silently
failed to extract all files from the debug adapter package
(https://github.com/vadimcn/codelldb/releases/download/v1.11.8/codelldb-win32-x64.vsix).
Particularly `python-lldb` folder was missing, which caused the warning.
The error occurred here:
cf7c64d77f/crates/util/src/archive.rs (L47)
And then gets ignored here:
cf7c64d77f/crates/dap/src/adapters.rs (L323-L326)
The simple fix is to update `async_zip` crate to version 0.0.18 where
this issue appears to be fixed. I also added logging instead of silently
ignoring the error, as I believe that would have helped to catch it
earlier.
To reproduce the original issue you can try to follow these steps:
0. (Optional) Remove/rename old codelldb adapter at
`%localappdata%\Zed\debug_adapters\CodeLLDB`. Restart Zed.
1. Create a simple Rust project. Make sure you use gnu toolchain (target
`x86_64-pc-windows-gnu`)
```rust
fn world() -> String {
"world".into()
}
fn main() {
let w = world();
println!("hello {}", w);
}
```
2. Put a breakpoint on line 7 (`println`)
3. In the command palette choose "debugger: start" and then select "run
*crate name*"
Screenshot before the fix:
<img width="893" height="411" alt="image"
src="https://github.com/user-attachments/assets/78097690-b55e-4989-bfa4-20452560f9fc"
/>
<details>
<summary>Console before the fix</summary>
```
Checking latest version of CodeLLDB...
Downloading from https://github.com/vadimcn/codelldb/releases/download/v1.11.8/codelldb-win32-x64.vsix...
Download complete
Could not initialize Python interpreter - some features will be unavailable (e.g. debug visualizers).
Console is in 'commands' mode, prefix expressions with '?'.
warning: (x86_64) D:\repro\target\x86_64-pc-windows-gnu\debug\repro.exe unable to locate separate debug file (dwo, dwp). Debugging will be degraded.
Launching: D:\repro\target\x86_64-pc-windows-gnu\debug\repro.exe
Launched process 13836 from 'D:\repro\target\x86_64-pc-windows-gnu\debug\repro.exe'
error: repro.exe [0x0000000000002074]: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x000000000000001a) attribute, but range extraction failed (invalid range list offset 0x1a), please file a bug and attach the file at the start of this error message
error: repro.exe [0x000000000000208c]: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x0000000000000025) attribute, but range extraction failed (invalid range list offset 0x25), please file a bug and attach the file at the start of this error message
error: repro.exe [0x00000000000020af]: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x0000000000000030) attribute, but range extraction failed (invalid range list offset 0x30), please file a bug and attach the file at the start of this error message
error: repro.exe [0x00000000000020c4]: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x000000000000003b) attribute, but range extraction failed (invalid range list offset 0x3b), please file a bug and attach the file at the start of this error message
error: repro.exe [0x00000000000020fc]: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x0000000000000046) attribute, but range extraction failed (invalid range list offset 0x46), please file a bug and attach the file at the start of this error message
error: repro.exe [0x0000000000002130]: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x0000000000000046) attribute, but range extraction failed (invalid range list offset 0x46), please file a bug and attach the file at the start of this error message
> ? w
< {...}
```
</details>
Screenshot after the fix:
<img width="634" height="295" alt="image"
src="https://github.com/user-attachments/assets/67e36a64-97d2-406c-9216-7ac5b01f4101"
/>
<details>
<summary>Console after the fix</summary>
```
Checking latest version of CodeLLDB...
Downloading from https://github.com/vadimcn/codelldb/releases/download/v1.11.8/codelldb-win32-x64.vsix...
Download complete
Console is in 'commands' mode, prefix expressions with '?'.
Loading Rust formatters from C:\Users\Vasyl\.rustup\toolchains\1.91.1-x86_64-pc-windows-msvc\lib/rustlib/etc
warning: (x86_64) D:\repro\target\x86_64-pc-windows-gnu\debug\repro.exe unable to locate separate debug file (dwo, dwp). Debugging will be degraded.
Launching: D:\repro\target\x86_64-pc-windows-gnu\debug\repro.exe
Launched process 10364 from 'D:\repro\target\x86_64-pc-windows-gnu\debug\repro.exe'
error: repro.exe [0x0000000000002074]: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x000000000000001a) attribute, but range extraction failed (invalid range list offset 0x1a), please file a bug and attach the file at the start of this error message
error: repro.exe [0x000000000000208c]: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x0000000000000025) attribute, but range extraction failed (invalid range list offset 0x25), please file a bug and attach the file at the start of this error message
error: repro.exe [0x00000000000020af]: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x0000000000000030) attribute, but range extraction failed (invalid range list offset 0x30), please file a bug and attach the file at the start of this error message
error: repro.exe [0x00000000000020c4]: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x000000000000003b) attribute, but range extraction failed (invalid range list offset 0x3b), please file a bug and attach the file at the start of this error message
error: repro.exe [0x00000000000020fc]: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x0000000000000046) attribute, but range extraction failed (invalid range list offset 0x46), please file a bug and attach the file at the start of this error message
error: repro.exe [0x0000000000002130]: DIE has DW_AT_ranges(DW_FORM_sec_offset 0x0000000000000046) attribute, but range extraction failed (invalid range list offset 0x46), please file a bug and attach the file at the start of this error message
> ? w
< "world"
```
</details>
This fixes#33753
Release Notes:
- util: Fixed archive::extract_zip failing to extract some archives
### What this solves
This PR adds support for HTTP and SSE (Server-Sent Events) transports to
Zed's context server implementation, enabling communication with remote
MCP servers. Currently, Zed only supports local MCP servers via stdio
transport. This limitation prevents users from:
- Connecting to cloud-hosted MCP servers
- Using MCP servers running in containers or on remote machines
- Leveraging MCP servers that are designed to work over HTTP/SSE
### Why it's important
The MCP (Model Context Protocol) specification includes HTTP/SSE as
standard transport options, and many MCP server implementations are
being built with these transports in mind. Without this support, Zed
users are limited to a subset of the MCP ecosystem. This is particularly
important for:
- Enterprise users who need to connect to centralized MCP services
- Developers working with MCP servers that require network isolation
- Users wanting to leverage cloud-based context providers (e.g.,
knowledge bases, API integrations)
### Implementation approach
The implementation follows Zed's existing architectural patterns:
- **Transports**: Added `HttpTransport` and `SseTransport` to the
`context_server` crate, built on top of the existing `http_client` crate
- **Async handling**: Uses `gpui::spawn` for network operations instead
of introducing a new Tokio runtime
- **Settings**: Extended `ContextServerSettings` enum with a `Remote`
variant to support URL-based configuration
- **UI**: Updated the agent configuration UI with an "Add Remote Server"
option and dedicated modal for remote server management
### Changes included
- [x] HTTP transport implementation with request/response handling
- [x] SSE transport for server-sent events streaming
- [x] `build_transport` function to construct appropriate transport
based on URL scheme
- [x] Settings system updates to support remote server configuration
- [x] UI updates for adding/editing remote servers
- [x] Unit tests using `FakeHttpClient` for both transports
- [x] Integration tests (WIP)
- [x] Documentation updates (WIP)
### Testing
- Unit tests for both `HttpTransport` and `SseTransport` using mocked
HTTP client
- Manual testing with example MCP servers over HTTP/SSE
- Settings validation and UI interaction testing
### Screenshots/Recordings
[TODO: Add screenshots of the new "Add Remote Server" UI and
configuration modal]
### Example configuration
Users can now configure remote MCP servers in their `settings.json`:
```json
{
"context_servers": {
"my-remote-server": {
"enabled": true,
"url": "http://localhost:3000/mcp"
}
}
}
```
### AI assistance disclosure
I used AI to help with:
- Understanding the MCP protocol specification and how HTTP/SSE
transports should work
- Reviewing Zed's existing patterns for async operations and suggesting
consistent approaches
- Generating boilerplate for test cases
- Debugging SSE streaming issues
All code has been manually reviewed, tested, and adapted to fit Zed's
architecture. The core logic, architectural decisions, and integration
with Zed's systems were done with human understanding of the codebase.
AI was primarily used as a reference tool and for getting unstuck on
specific technical issues.
Release notes:
* You can now configure MCP Servers that connect over HTTP in your
settings file. These are not yet available in the extensions API.
```
{
"context_servers": {
"my-remote-server": {
"enabled": true,
"url": "http://localhost:3000/mcp"
}
}
}
```
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
This should make it easier to correlate Sentry reports with user reports
and
github issues (for users who have diagnostics enabled)
Release Notes:
- N/A
Closes#40888
This updates runtimed to the latest version, which handles the
"starting" variant of `execution_state`. It actually handles a bunch of
other variants that are not documented in the protocol (see
https://jupyter-client.readthedocs.io/en/stable/messaging.html#kernel-status),
like "starting", "terminating", etc. I added implementations for these
variants as well.
Release Notes:
- Fixed issue that prevented the Ark kernel from working in Zed
(#40888).
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Automatically retry the agent's LLM completion requests when the
provider returns 429 Too Many Requests. Uses the Retry-After header to
determine the retry delay if it is available.
Many providers are frequently overloaded or have low rate limits. These
providers are essentially unusable without automatic retries.
Tested with Cerebras configured via openai_compatible.
Related: #31531
Release Notes:
- Added automatic retries for OpenAI-compatible LLM providers
---------
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
This is an in-progress work on changing how task scheduler affects
performance of project search. Instead of relying on tasks being
executed at a discretion of the task scheduler, we want to experiment
with having a set of "agents" that prioritize driving in-progress
project search matches to completion over pushing the whole thing to
completion. This should hopefully significantly improve throughput &
latency of project search.
This PR has been reverted previously in #40831.
Release Notes:
- Improved project search performance in local projects.
---------
Co-authored-by: Smit Barmase <smit@zed.dev>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
New rustc starts to output a few warnings, fix them by updating the
corresponding packages.
<details>
<summary>Incompatibility notes</summary>
```
The following warnings were discovered during the build. These warnings
are an
indication that the packages contain code that will become an error in a
future release of Rust. These warnings typically cover changes to close
soundness problems, unintended or undocumented behavior, or critical
problems
that cannot be fixed in a backwards-compatible fashion, and are not
expected
to be in wide use.
Each warning should contain a link for more information on what the
warning
means and how to resolve it.
To solve this problem, you can try the following approaches:
- Some affected dependencies have newer versions available.
You may want to consider updating them to a newer version to see if the
issue has been fixed.
num-bigint-dig v0.8.4 has the following newer versions available: 0.8.5,
0.9.0, 0.9.1
- If the issue is not solved by updating the dependencies, a fix has to
be
implemented by those dependencies. You can help with that by notifying
the
maintainers of this problem (e.g. by creating a bug report) or by
proposing a
fix to the maintainers (e.g. by creating a pull request):
- num-bigint-dig@0.8.4
- Repository: https://github.com/dignifiedquire/num-bigint
- Detailed warning command: `cargo report future-incompatibilities --id
1 --package num-bigint-dig@0.8.4`
- If waiting for an upstream fix is not an option, you can use the
`[patch]`
section in `Cargo.toml` to use your own version of the dependency. For
more
information, see:
https://doc.rust-lang.org/cargo/reference/overriding-dependencies.html#the-patch-section
The package `num-bigint-dig v0.8.4` currently triggers the following
future incompatibility lints:
> warning: macro `vec` is private
> -->
/Users/someonetoignore/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/num-bigint-dig-0.8.4/src/biguint.rs:490:22
> |
> 490 | BigUint::new(vec![1])
> | ^^^
> |
> = warning: this was previously accepted by the compiler but is being
phased out; it will become a hard error in a future release!
> = note: for more information, see issue #120192
<https://github.com/rust-lang/rust/issues/120192>
>
> warning: macro `vec` is private
> -->
/Users/someonetoignore/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/num-bigint-dig-0.8.4/src/biguint.rs:2005:9
> |
> 2005 | vec![0]
> | ^^^
> |
> = warning: this was previously accepted by the compiler but is being
phased out; it will become a hard error in a future release!
> = note: for more information, see issue #120192
<https://github.com/rust-lang/rust/issues/120192>
>
> warning: macro `vec` is private
> -->
/Users/someonetoignore/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/num-bigint-dig-0.8.4/src/biguint.rs:2027:16
> |
> 2027 | return vec![b'0'];
> | ^^^
> |
> = warning: this was previously accepted by the compiler but is being
phased out; it will become a hard error in a future release!
> = note: for more information, see issue #120192
<https://github.com/rust-lang/rust/issues/120192>
>
> warning: macro `vec` is private
> -->
/Users/someonetoignore/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/num-bigint-dig-0.8.4/src/biguint.rs:2313:13
> |
> 2313 | vec![0]
> | ^^^
> |
> = warning: this was previously accepted by the compiler but is being
phased out; it will become a hard error in a future release!
> = note: for more information, see issue #120192
<https://github.com/rust-lang/rust/issues/120192>
>
> warning: macro `vec` is private
> -->
/Users/someonetoignore/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/num-bigint-dig-0.8.4/src/prime.rs:138:22
> |
> 138 | let mut moduli = vec![BigUint::zero(); prime_limit];
> | ^^^
> |
> = warning: this was previously accepted by the compiler but is being
phased out; it will become a hard error in a future release!
> = note: for more information, see issue #120192
<https://github.com/rust-lang/rust/issues/120192>
>
> warning: macro `vec` is private
> -->
/Users/someonetoignore/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/num-bigint-dig-0.8.4/src/bigrand.rs:319:25
> |
> 319 | let mut bytes = vec![0u8; bytes_len];
> | ^^^
> |
> = warning: this was previously accepted by the compiler but is being
phased out; it will become a hard error in a future release!
> = note: for more information, see issue #120192
<https://github.com/rust-lang/rust/issues/120192>
>
```
</details>
Release Notes:
- N/A
Closes #ISSUE
Improves error reporting for various failure modes of zeta2, including
failing to parse the `<old_text>`/`<new_text>` pattern, and the contents
of `<old_text>` failing to match.
Additionally, makes it so that evals are checked out into a worktree
with the _repo_ name instead of the _example_ name, in order to make
sure that the eval name has no influence on the models prediction. The
repo name worktrees are still namespaced by the example name like
`{example_name}/{repo_name}` to ensure evals pointing to the same repo
do not conflict.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Agus <agus@zed.dev>
Adds a simple notification when cloning a repo using the integrated git
clone on Zed. Before this, the user had no feedback after starting the
cloning action.
Demo:
https://github.com/user-attachments/assets/72fcdf1b-fc99-4fe5-8db2-7c30b170f12f
Not sure about that icon I'm using for the animation, but that can be
easily changed.
Release Notes:
- Added notification when cloning a repo from zed
We've had several outages with a proximate cause of "vercel is
complicated",
and auto-update is considered a critical feature; so lets not use vercel
for
that.
Release Notes:
- Auto Updates (and remote server binaries) are now downloaded via
https://cloud.zed.dev instead of https://zed.dev. As before, these URLs
redirect to the GitHub release for actual downloads.
Since we removed the filtering step during context gathering, we want
the model to perform more targeted searches. This PR tweaks search tool
schema allowing the model to search within syntax nodes such as `impl`
blocks or methods.
This is what the query schema looks like now:
```rust
/// Search for relevant code by path, syntax hierarchy, and content.
#[derive(Debug, Clone, Serialize, Deserialize, JsonSchema)]
pub struct SearchToolQuery {
/// 1. A glob pattern to match file paths in the codebase to search in.
pub glob: String,
/// 2. Regular expressions to match syntax nodes **by their first line** and hierarchy.
///
/// Subsequent regexes match nodes within the full content of the nodes matched by the previous regexes.
///
/// Example: Searching for a `User` class
/// ["class\s+User"]
///
/// Example: Searching for a `get_full_name` method under a `User` class
/// ["class\s+User", "def\sget_full_name"]
///
/// Skip this field to match on content alone.
#[schemars(length(max = 3))]
#[serde(default)]
pub syntax_node: Vec<String>,
/// 3. An optional regular expression to match the final content that should appear in the results.
///
/// - Content will be matched within all lines of the matched syntax nodes.
/// - If syntax node regexes are provided, this field can be skipped to include as much of the node itself as possible.
/// - If no syntax node regexes are provided, the content will be matched within the entire file.
pub content: Option<String>,
}
```
We'll need to keep refining this, but the core implementation is ready.
Release Notes:
- N/A
---------
Co-authored-by: Ben <ben@zed.dev>
Co-authored-by: Max <max@zed.dev>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Closes#40576
This PR makes Conda activation configurable and transparent by adding a
`terminal.detect_venv.on.conda_manager` setting (`"auto" | "conda" |
"mamba" | "micromamba"`, default `"auto"`), updating Python environment
activation to honor this preference (or the detected manager executable)
and fall back to `conda` when necessary.
The preference is passed via `ZED_CONDA_MANAGER` from the terminal
settings, and the activation command is built accordingly (with proper
quoting for paths). Changes span
`zed/crates/terminal/src/terminal_settings.rs` (new `CondaManager` and
setting), `zed/crates/project/src/terminals.rs` (inject env var),
`zed/crates/languages/src/python.rs` (activation logic), and
`zed/assets/settings/default.json` (document the setting). Default
behavior remains unchanged for most users while enabling explicit
selection of `mamba` or `micromamba`.
Release Notes:
- Added: terminal.detect_venv.on.conda_manager setting to choose the
Conda manager (auto, conda, mamba, micromamba). Default: auto.
- Changed: Python Conda environment activation now respects the
configured manager, otherwise uses the detected environment manager
executable, and falls back to conda.
- Reliability: Activation commands quote manager paths to handle spaces
across platforms.
- Compatibility: No breaking changes; non-Conda environments are
unaffected; remote terminals are supported.
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Adds support for opening and displaying images in remote projects. The
server streams image data to the client in chunks, where the client then
reconstructs the image and displays it. This change includes:
- Adding `image` crate as a dependency for remote_server
- Implementing `ImageStore` for remote access
- Creating proto definitions for image-related messages
- Adding handlers for creating images for peers
- Computing image metadata from bytes instead of reading from disk for
remote images
Closes#20430Closes#39104Closes#40445
Release Notes:
- Added support for image preview in remote sessions.
- Fixed#39104
<img width="982" height="551" alt="image"
src="https://github.com/user-attachments/assets/575428a3-9144-4c1f-b76f-952019ea14cc"
/>
<img width="978" height="547" alt="image"
src="https://github.com/user-attachments/assets/fb58243a-4856-4e73-bb30-8d5e188b3ac9"
/>
---------
Co-authored-by: Julia Ryan <juliaryan3.14@gmail.com>
- Updated `blame_ui.rs`, `branch_picker.rs`, `commit_tooltip.rs`, and
`commit_view.rs` to replace the previous timestamp formatting with
`chrono` for better accuracy in local time representation.
- Introduced `chrono::Local::now().offset().local_minus_utc()` to obtain
the local offset for timestamp formatting.
Closes#40878
Release Notes:
- Improved timestamp handling in various Git UI components for enhanced
user experience.
## Summary
Fixes#36754
This PR fixes an issue where LSPs fail to spawn after the crash handler
is initialized.
## Problem
After PR #35263 added minidump crash reporting, some users experienced
LSP spawn failures. The issue manifests as:
- LSPs fail to spawn with no clear error messages
- The problem only occurs after crash handler initialization
- LSPs work when a debugger is attached, revealing a timing issue
### Root Cause
The crash handler installs Mach exception ports for minidump generation.
Due to a timing issue, child processes inherit these exception ports
before they're fully stabilized, which can block child process spawning.
## Solution
Reset exception ports in child processes using the `pre_exec()` hook,
which runs after `fork()` but before `exec()`. This prevents children
from inheriting the parent's crash handler exception ports.
### Implementation
- Adds macOS-specific implementation of `new_smol_command()` that resets
exception ports before exec
- Calls `task_set_exception_ports` to reset all exception ports to
`MACH_PORT_NULL`
- Graceful error handling: logs warnings but doesn't fail process
spawning if port reset fails
Release Notes:
- Fixed LSPs failing to spawn on some macOS systems
---------
Co-authored-by: Julia Ryan <juliaryan3.14@gmail.com>
Related discussions #26084
Worktree creations are implemented similar to how branch creations are
handled on the branch picker (the user types a new name that's not on
the list and a new entry option appears to create a new branch with that
name).
https://github.com/user-attachments/assets/39e58983-740c-4a91-be88-57ef95aed85b
With this picker you have a few workflows:
- Open the picker and type the name of a branch that's checked out on an
existing worktree:
- Press enter to open the worktree on a new window
- Press ctrl-enter to open the worktree and replace the current window
- Open the picker and type the name of a new branch or an existing one
that's not checked out in another worktree:
- Press enter to create the worktree and open in a new window. If the
branch doesn't exists, we will create a new one based on the branch you
have currently checked out. If the branch does exists then we create a
worktree with that branch checked out.
- Press ctrl-enter to do everything on the previous point but instead,
replace the current window with the new worktre.
- Open the picker and type the name of a new branch or an existing one
that's not checked out in another worktree:
- If a default branch is detected on the repo, you can create a new
worktree based on that branch by pressing ctrl-enter or
ctrl-shift-enter. The first one will open a new window and the last one
will replace the current one.
Note: If you preffer to not use the system prompt for choosing a
directory, you can set `"use_system_path_prompts": false` in zed
settings.
Release Notes:
- Added git worktree picker to open a git worktree on a new window or
replace the current one
- Added git worktree creation action
---------
Co-authored-by: Cole Miller <cole@zed.dev>
We see `test_extension_store_with_test_extension` hang in untarring the
WASI SDK some times.
In lieu of trying to debug the problem, let's try shelling out for now
in the hope that the test becomes more reliable.
There's a bit of risk here because we're using async-tar for other
things (but probably not 300Mb tar files...)
Assisted-By: Zed AI
Closes #ISSUE
Release Notes:
- N/A
This PR adds a `zeta zeta2 predict` subcommand that takes an edit
prediction example markdown file as an argument, and performs zeta2's
prediction, showing the retrieved context and the predicted edit.
* [x] Apply uncommitted diff to get repo into the right state.
* [x] Apply edits in edit history
* [x] Display predicted edits as unified diff, regardless of model
output format
Release Notes:
- N/A
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Ben Kunkle <ben.kunkle@gmail.com>
Prior we were only updating the diagnostics pane when it is either
unfocued, saved or when a disk based diagnostic run finishes (aka cargo
check). The reason for this is simple, we do not want to take away the
excerpt under the users cursor while they are typing if they manage to
fix the diagnostic. Additionally we need to prevent dropping the changed
buffer before it is saved.
Delaying updates was a simple way to work around these kind of issues,
but comes at a huge annoyance that the diagnostics pane is not actually
reflecting the current state of the world but some snapshot of it
instead making it less than ideal to work within it for languages that
do not leverage disk based diagnostics (that is not rust-analyzer, and
even for rust-analyzer its annoying).
This PR changes this. We now always live update the view but take care
to retain unsaved buffers as well as buffers that contain a cursor in
them (as well as some other "checkpoint" properties).
Release Notes:
- Improved diagnostics pane to live update when editing within its
editor
Adds a `convert-example` subcommand to the zeta cli that converts eval
examples from/to `json`, `toml`, and `md` formats.
Release Notes:
- N/A
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Closes#38345, #34882, #33280
Debugpy has four distinct configuration scenarios, which are:
1. launch
2. attach with process id
3. attach with listen
4. attach with connect
Spawning Debugpy directly works with the first three scenarios but not
with "attach with connect". Which requires host/port arguments being
passed in both with an attach request and when starting up Debugpy. This
PR passes in the right arguments when spawning Debugpy in an attach with
connect scenario, thus fixing the bug.
The VsCode extension comment that explains this:
98f5b93ee4/src/extension/debugger/adapter/factory.ts (L43-L51)
Release Notes:
- debugger: Fix Python attach-based sessions not working with `connect`
or `port` arguments
We'll now perform all searches from the context model concurrently, and
combine queries for the same glob into one reducing the total number of
project searches.
For better readability, the debug context view now displays each
top-level regex alternation individually, grouped by its corresponding
glob:
<img width="1592" height="672" alt="CleanShot 2025-10-29 at 19 56 03@2x"
src="https://github.com/user-attachments/assets/f6e8408e-09d6-4e27-ba11-a739a772aa12"
/>
Release Notes:
- N/A
