Release Notes:

- Adds support for `:[range]w {file}`
  - This writes the lines in the range to the specified
- Adds support for `:[range]w`
  - This replaces the current file with the selected lines

Closes #41467 

My first PR in Zed, any guidance or tips are appreciated.

This fixes the flickering/resize loop that occurred on the tab
immediately to the right of a pinned tab.

Removed the conditional border on the pinned tabs container. The border
was a visual indicator to show when unpinned tabs were scrolled, but it
wasn't essential and was causing the layout thrashing.

Release Notes:

- Fixed

---------

Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>

Fixed outline panel space key behavior by removing duplicate toggle call

The `open_selected_entry` function in `outline_panel.rs` was incorrectly
calling `self.toggle_expanded(&selected_entry, window, cx)` in addition
to its primary logic, causing the space key to both open/close entries
AND toggle their expanded state. Removed the redundant `toggle_expanded`
call to achieve the intended behavior.

Closes #41711

Release Notes:

- Fixed issue with the outline panel where pressing space would cause an
open selected entry to collapse and cause a closed selected entry to
open.

---------

Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>

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>

Release Notes:

- Fixed logging into Gemini CLI and Claude Code when remoting and
authenticating via CLI

Co-authored-by: Lukas Wirth <me@lukaswirth.dev>

Summary

Fixes UI scaling issue that occurs when starting Zed after disconnecting
an external monitor on macOS. The window's scale factor and drawable
size are now properly updated when the window changes screens.

Problem Description

When an external monitor is disconnected and Zed is started with only
the built-in screen active, the UI scale becomes incorrect. This happens
because:

1. macOS triggers the `window_did_change_screen` callback when a window
moves between displays (including when displays are disconnected)
2. The existing implementation only restarted the display link but
didn't update the window's scale factor or drawable size
3. This left the window with stale scaling information from the previous
display configuration

Root Cause

The `window_did_change_screen` callback in
`crates/gpui/src/platform/mac/window.rs` was missing the logic to update
the window's scale factor and drawable size when moving between screens.
This logic was only present in the `view_did_change_backing_properties
callback`, which isn't triggered when external monitors are
disconnected.

Solution

- Extracted common logic: Created a new `update_window_scale_factor()`
function that encapsulates the scale factor and drawable size update
logic
- Added scale factor update to screen change: Modified
`window_did_change_screen` to call this function after restarting the
display link
- Refactored existing code: Updated `view_did_change_backing_properties`
to use the new shared function, reducing code duplication

The fix ensures that whenever a window changes screens (due to monitor
disconnect, reconnect, or manual movement), the scale factor, drawable
size, and renderer state are properly synchronized.

Testing

- ✅ Verified that UI scaling remains correct after disconnecting
external monitor
- ✅ Confirmed that reconnecting external monitor works properly
- ✅ Tested that manual window movement between displays updates scaling
correctly
- ✅ No regressions observed in normal window operations

To verity my fix worked I had to copy my preview workspace over my dev
workspace, once I had done this I could reproduce the issue on main
consistently. After switching to the branch with this fix the issue was
resolved.

The fix is similar to what was done on
https://github.com/zed-industries/zed/pull/35686 (Windows)

Closes #37245 #38229

Release Notes:

- Fixed: Update scale factor and drawable size when macOS window changes
screen

---------

Co-authored-by: Kate <work@localcc.cc>

Release Notes:

- N/A

Closes #ISSUE

The namespace runners mount the `target` directory to the cache drive,
so `rm -rf target` would fail with `Device Busy`. Instead we now do `rm
-rf target/* target/.*` to remove all files (including hidden files)
from the `target` directory, without removing the target directory
itself

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Whenever right-click was used on the editor, the pane's tab buttons
would flicker, which was confirmed to happen because of the following
check:

```
self.focus_handle.contains_focused(window, cx)
    || self
        .active_item()
        .is_some_and(|item| {
            item.item_focus_handle(cx).contains_focused(window, cx)
        })
```

This check was returning `false` right after right-clicking but
returning `true` right after. When digging into it a little bit more,
this appears to be happening because the editor's `MouseContextMenu`
relies on `ContextMenu` which is rendered in a deferred fashion but
`MouseContextMenu` updates the window's focus to it instantaneously.

Since the `ContextMenu` is rendered in a deferred fashion, its focus
handle is not yet a descendant of the editor (pane's active item) focus
handle, so the `contains_focused(window, cx)` call would return `false`,
with it returning `true` after the menu was rendered.

This commit updates the `MouseContextMenu::new` function to leverage
`cx.on_next_frame` and ensure that the focus is only moved to the
`ContextMenu` 2 frames later, ensuring that by the time the focus is
moved, the `ContextMenu`'s focus handle is a descendant of the editor's.

Closes #41771 

Release Notes:

- Fixed pane's tab buttons flickering when using right-click on the
editor

Just on nightly.

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Co-authored-by: Lukas Wirth <me@lukaswirth.dev>

This enables clap's [wrap-help] feature and sets max_term_width to wrap
after 100 columns (the value clap is planning to default to in clap-v5).

This commit also adds blank lines which cause clap to split longer doc
comments into separate help (displayed for `-h`) and long_help
(displayed for `--help`) messages, as per [doc-processing].

[wrap-help]:
https://docs.rs/clap/4.5.49/clap/_features/index.html#optional-features
[doc-processing]:
https://docs.rs/clap/4.5.49/clap/_derive/index.html#pre-processing

![before: some lines of help text stretch across the whole screen.
after: all lines are wrapped at 100 columns, and some manual linebreaks
are preserved where it makes sense (in particular, when listing the
user-data-dir locations on each
platform)](https://github.com/user-attachments/assets/359067b4-5ffb-4fe3-80bd-5e1062986417)


Release Notes:

- N/A

Release Notes:

- N/A

Release Notes:

- N/A

Closes #31346

Release Notes:

- Agent commands no longer show up in the command palette when `agent`
is disabled. Same for edit predictions.

Release Notes:

- N/A

Hides the aggregated scores if only one example/repetition ran. It also
fixes an issue with the expected context scoring.

Release Notes:

- N/A

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>

Closes #38227

Release Notes:

- Added tilde expansion support for LSP binary path in `settings.json`

This PR adds support for `HTML` href elements. It also refactored the
way we stored the regions, this was done because otherwise I had to add
2 extra arguments to each `HTML` parser method. It's now also more
inline with how we have done it for the highlights.

**Small note**: the markdown parser only supports HTML href tags inside
a paragraph tag. So adding them as a root node will result in just
showing the inner text. This is a limitation of the markdown parser we
use itself.

**Before**
<img width="935" height="174" alt="Screenshot 2025-11-08 at 15 40 28"
src="https://github.com/user-attachments/assets/42172222-ed49-4a4b-8957-a46330e54c69"
/>

**After**
<img width="1026" height="180" alt="Screenshot 2025-11-08 at 15 29 55"
src="https://github.com/user-attachments/assets/9e139c2d-d43a-4952-8d1f-15eb92966241"
/>

**Example code**
```markdown
<p>asd <a href="https://example.com">Link Text</a> more text</p>
<p><a href="https://example.com">Link Text</a></p>

[Duck Duck Go](https://duckduckgo.com)
```

**TODO**:
- [x] Add tests

cc @bennetbo

Release Notes:

- Markdown Preview: Add support for `HTML` href elements.

---------

Co-authored-by: Bennet Bo Fenner <bennet@zed.dev>

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>

Closes https://github.com/zed-industries/zed/issues/42618

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Relands https://github.com/zed-industries/zed/pull/42480

Release Notes:

- Clicking the multi-buffer header file name or the "Open file" button
now jumps to the most recent selection in that buffer, if one exists.

---------

Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>

## Summary

Fixes #42342

When installing a dev extension with long installation instructions, the
configuration modal would overflow and users couldn't scroll to see the
full content or interact with buttons at the bottom.

## Solution

This PR adds a `ScrollHandle` to the `ConfigureContextServerModal` and
passes it to the `Modal` component, enabling the built-in modal
scrolling capability. This ensures all content remains accessible
regardless of length.

## Changes

- Added `ScrollHandle` import to the ui imports
- Added `scroll_handle: ScrollHandle` field to
`ConfigureContextServerModal` struct
- Initialize `scroll_handle` with `ScrollHandle::new()` when creating
the modal
- Pass the scroll handle to `Modal::new()` instead of `None`

## Testing

- Built the changes locally
- Tested with extensions that have long installation instructions
- Verified scrolling works and all content is accessible
- Confirmed no regression for extensions with short descriptions

Release Notes:

- Fixed scrolling issue in extension configuration modal when
installation instructions overflow the viewport

---------

Co-authored-by: Finn Evers <finn.evers@outlook.de>

Address #40429

If an integration test is annotated with the ignore attribute, allow the
"debug: Test" option of the debug scenario or Code Action to run with
"--include-ignored"

Closes #40429

Release Notes:

- N/A

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 https://github.com/zed-industries/zed/issues/42594

Release Notes:

- Fixed remote server installation failing with nutshell

Fixes ZED-36P

Patching this over for now until I can figure out the cause of this

Release Notes:

- Fixed panic in diagnostics pane

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Release Notes:

- Pressing `u` after multiple `.` in rapid succession will now only undo
the latest repeat instead of all repeats.

---------

Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>

Closes #ISSUE

Release Notes:

- N/A

Closes #40923

Release Notes:

- Fixed the amount of newlines between copied lines from a multi-cursor
selection of multiple full-line copies.

---


https://github.com/user-attachments/assets/ab7474d6-0e49-4c29-9700-7692cd019cef

Closes #ISSUE

Release Notes:

- N/A

Fixes #39448

Several node version managers such as [volta](https://volta.sh) use thin
wrappers that locate the "real" node/npm binary with an env var that
points at their install root. When it finds this, it prepends the
correct directory to PATH, otherwise it'll check a hardcoded default
location and prepend that to PATH if it exists.

We were clearing env for npm subcommands, which meant that volta and co.
failed to locate the install root, and because they were installed via
scoop they don't use the default install path either so it simply
doesn't prepend anything to PATH (winget on the other hand installs
volta to the right place, which is why it worked when using that instead
of scoop to install volta @IllusionaryX).

So volta's npm wrapper executes a subcommand `npm`, but when that
doesn't prepend a different directory to PATH the first `npm` found in
PATH is that same wrapper itself, which horrifyingly causes itself to
re-exec continuously. I think they might have some logic to try to
prevent this using, you'll never guess, another env var that they set
whenever a volta wrapper execs something. Of course since we clear the
env that var also fails to propagate.

Removing env clearing (but keeping the prepending of npm path from your
settings) fixes these issues.

Release Notes:

- Fixed issues with scoop installations of mise/volta

Co-authored-by: John Tur <john-tur@outlook.com>

Release Notes:

- N/A

---------

Co-authored-by: Michael Sloan <mgsloan@gmail.com>
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Agus Zubiaga <agus@zed.dev>

Right now only one unit eval GitHub Action can be run at a time. This
permits them to run concurrently.

Release Notes:

- N/A

Adds a `--repeat` flag to the zeta eval that runs each example as many
times as specified. Also makes the output nicer in a few ways.

Release Notes:

- N/A

---------

Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Michael <michael@zed.dev>

See discussion in #24657. Recalled that I had a stashed change for this,
so polished it up

Release Notes:

- N/A

Closes #42134

Release Notes:

- Improved `pane: reopen closed item` to not reopen closed tabs.

Co-Authored-By: Claude

Release Notes:

- N/A

The existing sorting approach when faced with `Dir1`, `dir2`, `Dir3`,
would only get as far as comparing the stems without numbers (`dir` and
`Dir`), and then the lowercase-first tie breaker in that function would
determine that `dir2` should come first, resulting in an undesirable
order of `dir2`, `Dir1`, `Dir3`.

This patch defers tie-breaking until it's determined that there's no
other difference in the strings outside of case to order on, at which
point we tie-break to provide a stable sort.

Natural number sorting is still preserved, and mixing different cases
alphabetically (as opposed to all lowercase alpha, followed by all
uppercase alpha) is preserved.

Closes #41080


Release Notes:

- Fixed: ProjectPanel sorting bug

Screenshots:

Before | After
----|---
<img width="237" height="325" alt="image"
src="https://github.com/user-attachments/assets/6e92e8c0-2172-4a8f-a058-484749da047b"
/> | <img width="239" height="325" alt="image"
src="https://github.com/user-attachments/assets/874ad29f-7238-4bfc-b89b-fd64f9b8889a"
/>

I'm having trouble reasoning through what was previously going wrong
with `docs` in the before screenshot, but it also seems to now appear
alphabetically where you'd expect it with this patch

---------

Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>

Release Notes:

- N/A

---------

Co-authored-by: Julia Ryan <juliaryan3.14@gmail.com>

Closes #ISSUE

Release Notes:

- N/A

This adds additional comments which were left out from #42494 by
accident. Namely, it describes why we have additional custom
highlighting in `highlights.scm` for the Typescript grammar.

Release Notes:

- N/A

Fixed a typo in the docs

Release Notes:

- N/A

Closes #ISSUE

Release Notes:

- N/A *or* Added/Fixed/Improved ...

Closes #7844

This change uses tree-sitter highlights as a method of showing
typescript errors prettily, keeping regex as simple as possible:

<img width="832" height="446" alt="Screenshot 2025-11-11 at 3 40 24 PM"
src="https://github.com/user-attachments/assets/0b3b6cf1-4d4d-4398-b89b-ef5ec0df87ec"
/>

It covers three main areas:

1. Diagnostics

Diagnostics are now rendered with language-aware typescript, by
providing the project's language registry.

2. Vtsls

The LSP provider for typescript now implements the
`diagnostic_message_to_markdown` function in the `LspAdapter` trait, so
as to provide Diagnostics with \`\`\`typescript...\`\`\`-style code
blocks for any selection of typescript longer than one word. In the
single-word case, it simply wraps with \`\`

3. Typescript's `highlights.scm`

`vtsls` doesn't provide strictly valid typescript in much of its
messaging. Rather, it returns a message with snippets of typescript
values which are invalid. Tree-sitter was not properly highlighting
these snippets because it was expecting key-value formats. For instance:
```
type foo = { foo: string; bar: string; baz: number[] }
```
is valid, whereas simply
```
{ foo: string; bar: string; baz: number[] }
```
is not.

Therefore, highlights.scm needed to be adjusted in order to
pattern-match on literal values that might be returned from the vtsls
diagnostics messages. This was done by a) identifying arrow functions on
their own, and b) augmenting the `statment_block` pattern matching in
order to match on values which were clearly object literals.

This approach may not be exhaustive - I'm happy to work on any
additional cases we might identify from `vtsls` here - but hopefully
demonstrates an extensible approach to making these messages look nice,
without taking on the technical burden of extensive regex.

Release Notes:

- Show pretty TypeScript errors with language-aware Markdown.