Currently, `search::ReplaceNext` works only first time it is executed
because Zed switches the focus to the editor. It seems
`self.editor_focus` call is unnecessary.

Closes #17466

Release Notes:

- Fixed `Replace Next Match` command. Previously it worked once, then
Zed incorrectly switched the focus to the editor


https://github.com/user-attachments/assets/66ef61d6-1efe-43ca-8d8c-6b40540a9930

In accordance with #30327, I saw no reason for included files to get
special treatment, and I actually get use out of prefilling excluded
files because I like not to search symlinked files which, in my
workflow, use a naming convention.

This is simply implementing the same exact changes, but for excluded. It
was tested with `"space /": ["pane::DeploySearch", { "excluded_files":
"**/_*.tf" }]` and works just fine.

Release Notes:

- Added `excluded_files` to `pane::DeploySearch`.

This reduces 'touch crates/editor/src/editor.rs && cargo +nightly build'
from 8.9s to 8.5s. That same scenario used to take 8s less than a week
ago. :)
I'm measuring with nightly rustc, because it's compile times are better
than those of stable thanks to
https://github.com/rust-lang/rust/pull/138522

main (8.2s total):

![image](https://github.com/user-attachments/assets/767a2ac4-7bba-4147-bd16-9b09eed5b433)

[cargo-timing.html.zip](https://github.com/user-attachments/files/20364175/cargo-timing.html.zip)

#22be776 (7.5s total):

[cargo-timing-20250521T085303.892834Z.html.zip](https://github.com/user-attachments/files/20364391/cargo-timing-20250521T085303.892834Z.html.zip)

![image](https://github.com/user-attachments/assets/c4476df9-cb6e-4403-b0db-de00521f1fd0)


Release Notes:

- N/A

Missed because of lack of rebase

Release Notes:

- N/A

Builds on top of https://github.com/zed-industries/zed/pull/30942

This turns on incremental compilation and decreases extension
compilation times by up to another 41%
Putting us at roughly 92% improved extension load times from what is in
the app today.

Because we only have a static engine, I can't reset the cache between
every run. So technically the benchmarks are always running with a
warmed cache. So the first extension we load will take the 8.8ms, and
then any subsequent extensions will be closer to the measured time in
this benchmark.

This is also measuring the entire load process, not just the
compilation. However, since this is the loading we likely think of when
thinking about extensions, I felt it was likely more helpful to see the
impact on the overall time.

This works because our extensions are largely the same Wasm bytecode
(SDK code + std lib functions etc) with minor changes in the trait impl.
The more different that extensions implementation is, there will be less
benefit, however, there will always be a large part of every extension
that is always the same across extensions, so this should be a speedup
regardless.

I used `moka` to provide a bound to the cache. We could use a bare
`DashMap`, however if there was some issue this could lead to a memory
leak. `moka` has some slight overhead, but makes sure that we don't go
over 32mb while using an LRU-style mechanism for deciding which
compilation artifacts to keep.

I measured our current extensions to take roughly 512kb in the cache.
Which means with a cap of 32mb, we can keep roughly 64 *completely
novel* extensions with no overlap. Since our extensions will have more
overlap than this though, we can actually keep much more in the cache
without having to worry about it.

#### Before:

```
load/1                  time:   [8.8301 ms 8.8616 ms 8.8931 ms]
                        change: [-0.1880% +0.3221% +0.8679%] (p = 0.23 > 0.05)
                        No change in performance detected.
```

#### After:

```
load/1                  time:   [5.1575 ms 5.1726 ms 5.1876 ms]
                        change: [-41.894% -41.628% -41.350%] (p = 0.00 < 0.05)
                        Performance has improved.
```

Release Notes:

- N/A

Closes #30618

Release Notes:

- Fixed SOCKS proxy incorrectly always uses remote DNS resolution.

This PR adds a new `GET /users/look_up` endpoint for retrieving users by
various identifiers.

This endpoint can look up users by the following identifiers:

- Zed user ID
- Stripe Customer ID
- Stripe Subscription ID
- Email address
- GitHub login

Release Notes:

- N/A

When building for the `x86_64-unknown-linux-musl` target, the default
`openssl-dev` is compiled for the GNU toolchain, which causes a build
error due to missing OpenSSL. This PR fixes the issue by avoiding the
use of OpenSSL on non-macOS and non-Windows platforms.


Release Notes:

- N/A

Release Notes:

- N/A

This PR changes it so we only create a snapshot and get the syntax tree
for a buffer if we didn't detect that auto_close is enabled.

<img width="1205" alt="Screenshot 2025-05-16 at 21 10 28"
src="https://github.com/user-attachments/assets/1ada445f-77bc-4c7c-bffe-953f34ee5384"
/>


Release Notes:

- Improved project search performance

https://github.com/zed-industries/zed/issues/30972 brought up another
case where our context is not enough to track the actual source of the
issue: we get a general top-level error without inner error.

The reason for this was `.ok_or_else(|| anyhow!("failed to read HEAD
SHA"))?; ` on the top level.

The PR finally reworks the way we use anyhow to reduce such issues (or
at least make it simpler to bubble them up later in a fix).
On top of that, uses a few more anyhow methods for better readability.

* `.ok_or_else(|| anyhow!("..."))`, `map_err` and other similar error
conversion/option reporting cases are replaced with `context` and
`with_context` calls
* in addition to that, various `anyhow!("failed to do ...")` are
stripped with `.context("Doing ...")` messages instead to remove the
parasitic `failed to` text
* `anyhow::ensure!` is used instead of `if ... { return Err(...); }`
calls
* `anyhow::bail!` is used instead of `return Err(anyhow!(...));`

Release Notes:

- N/A

Closes #30972 

Release Notes:

- Fixed a bug that prevented the `copy permalink to line` action from
working on systems with older versions of git.

This PR hides hover info/diagnostic popovers when code action menu is
shown. We already hide hover info/diagnostic popover on code completion
menu trigger (handled on input).

Note: It is still possible to see hover popover if code completion or
code action menu is already open. This is intended behavior.

- [x] Test hover popover hides when code action is triggered

Release Notes:

- Fixed issue where info and diagnostic hover popovers were still
visible when code action menu is triggered.

Some providers sometimes send `{ "type": "text", "text": ... }` instead
of just the text as a string. Now we accept those instead of erroring.

Release Notes:

- N/A

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

Broken in: https://github.com/zed-industries/zed/pull/28559/files

Removes `editor::FindNextMatch` and `editor::FindPreviousMatch` from the
default sublime mappings. If you would like to use this, you will have
to add them to your user keymap. Reverts the previous behavior where
cmd-g / cmd-shift-g relies on the base keymap.

Linux:
```json
  {
    "context": "Editor && mode == full",
    "bindings": {
      "f3": "editor::FindNextMatch",
      "shift-f3": "editor::FindPreviousMatch"
    }
  }
```

MacOS:
```json
  {
    "context": "Editor && mode == full",
    "bindings": {
      "cmd-g": "editor::FindNextMatch",
      "cmd-shift-g": "editor::FindPreviousMatch"
    }
  },
```


Release Notes:

- Fixed a regression in Sublime Text keymap for find next/previous in
the search bar

Closes: #30730
It conflicts with the `>` key on the Czech keyboard layout  
If you want the previous behavior, add `"alt-.": ["terminal::SendText",
"\u001b."]` to your keymap under the `Terminal` context.

Release Notes: 

- Improved the default terminal keybind to not conflict on Czech
keyboards

Co-authored-by: Peter Tripp <peter@zed.dev>

Global settings were implemented in #30444, but `Settings`
implementations need to consider that source for it to be useful. This
PR does just that for `TelemetrySettings` so these can be controlled via
global settings.

Release Notes:

- N/A

Closes: #30523

Release Notes:

- linux: Reverted the ability to paste images on X11, as the change
broke pasting from some external applications

This eval checks that Edit Agent can create an empty file without
writing its thoughts into it. This issue is not specific to empty files,
but it's easier to reproduce with them.

For some mysterious reason, I could easily reproduce this issue roughly
90% of the time in actual Zed. However, once I extract the exact LLM
request before the failure point and generate from that, the
reproduction rate drops to 2%!

Things I've tried to make sure it's not a fluke: disabling prompt
caching, capturing the LLM request via a proxy server, running the
prompt on Claude separately from evals. Every time it was mostly giving
good outcomes, which doesn't match my actual experience in Zed.

At some point I discovered that simply adding one insignificant space or
a newline to the prompt suddenly results in an outcome I tried to
reproduce almost perfectly.

This weirdness happens even outside the Zed code base and even when
using a different subscription. The result is the same: an extra newline
or space changes the model behavior significantly enough, so that the
pass rate drops from 99% to 0-3%

I have no explanation to this.


Release Notes:

- N/A

Reverts zed-industries/zed#31022

Sorry @mikayla-maki, I found that things are more complicated than I
thought.

The lines returned by shape_text must maintain the same length as all
the original characters, otherwise the subsequent offset needs to always
consider the difference of `\r\n` or `\n` to do the offset.

Before, we only needed to add +1 after each offset after the line, but
now we need to consider +1 or +2, which is much more complicated.

We now show on the breakpoint itself whether it can ever be hit.

![image](https://github.com/user-attachments/assets/148d7712-53c9-4a0a-9fc0-4ff80dec5fb1)

Release Notes:

- N/A

---------

Signed-off-by: Umesh Yadav <git@umesh.dev>
Co-authored-by: Anthony <anthony@zed.dev>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Danilo Leal <67129314+danilo-leal@users.noreply.github.com>
Co-authored-by: Agus Zubiaga <hi@aguz.me>
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Richard Feldman <oss@rtfeldman.com>
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: peppidesu <bakker.pepijn@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Ben Kunkle <ben.kunkle@gmail.com>
Co-authored-by: Jens Krause <47693+sectore@users.noreply.github.com>
Co-authored-by: Bennet Bo Fenner <bennet@zed.dev>
Co-authored-by: Max Nordlund <max.nordlund@gmail.com>
Co-authored-by: Finn Evers <dev@bahn.sh>
Co-authored-by: tidely <43219534+tidely@users.noreply.github.com>
Co-authored-by: Sergei Kartsev <kartsevsb@gmail.com>
Co-authored-by: Shardul Vaidya <31039336+5herlocked@users.noreply.github.com>
Co-authored-by: Chris Kelly <amateurhuman@gmail.com>
Co-authored-by: Peter Tripp <peter@zed.dev>
Co-authored-by: Umesh Yadav <23421535+imumesh18@users.noreply.github.com>
Co-authored-by: Julia Ryan <juliaryan3.14@gmail.com>
Co-authored-by: Cole Miller <m@cole-miller.net>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Co-authored-by: william341 <wwokwilliam@gmail.com>
Co-authored-by: Liam <33645555+lj3954@users.noreply.github.com>
Co-authored-by: AidanV <aidanvanduyne@gmail.com>
Co-authored-by: imumesh18 <umesh4257@gmail.com>
Co-authored-by: d1y <chenhonzhou@gmail.com>
Co-authored-by: AidanV <84053180+AidanV@users.noreply.github.com>
Co-authored-by: Anthony Eid <56899983+Anthony-Eid@users.noreply.github.com>
Co-authored-by: 张小白 <364772080@qq.com>
Co-authored-by: THELOSTSOUL <1095533751@qq.com>
Co-authored-by: Ron Harel <55725807+ronharel02@users.noreply.github.com>
Co-authored-by: Tristan Hume <tristan@anthropic.com>
Co-authored-by: Stanislav Alekseev <43210583+WeetHet@users.noreply.github.com>
Co-authored-by: Joseph T. Lyons <JosephTLyons@gmail.com>
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Oleksiy Syvokon <oleksiy@zed.dev>
Co-authored-by: Thomas David Baker <bakert@gmail.com>
Co-authored-by: Nate Butler <iamnbutler@gmail.com>
Co-authored-by: Mikayla Maki <mikayla@zed.dev>
Co-authored-by: Rob McBroom <github@skurfer.com>
Co-authored-by: CharlesChen0823 <yongchen0823@gmail.com>

Closes #ISSUE

Release Notes:

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

This PR makes it so we only create a Zed Free subscription if there is
no other active subscription, rather than just having another Zed Free
subscription.

Release Notes:

- N/A

Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>

Release Notes:

- N/A

---

Today I check the shape_text result on Windows, I get:

<img width="409" alt="屏幕截图 2025-05-20 222908"
src="https://github.com/user-attachments/assets/3ee93911-3de1-4e01-9433-00c626fc2369"
/>

Here the `shape_text` split logic I think it should use `lines` method,
not `split('\n')`, the newline on Windows is `\r\n`.

Release Notes:

- N/A

---


When we use `window_handle` to draw WebView on Windows, this will crash
by:

This error caused by when used WebView2.

```
thread 'main' panicked at crates\gpui\src\app\async_context.rs:91:28:
already borrowed: BorrowMutError
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
thread 'main' panicked at library\core\src\panicking.rs:221:5:
panic in a function that cannot unwind
```

Try this https://github.com/tauri-apps/wry/pull/1383 on Windows can
replay the crash.

In fact, we had done [a similar fix around August last
year](https://github.com/huacnlee/zed/pull/6), but we used the unsafe
method to avoid crashes in that version, we felt that it was not a good
change, so we do not make PR.

Today @sunli829 thought about it again and changed the method. Now using
`try_borrow_mut` is similar to the previous `borrow_mut`.


https://github.com/zed-industries/zed/blob/691de6b4b36d3ada91a1e238904b065eec454188/crates/gpui/src/app.rs#L70-L78

I have tested to start Zed by those changes, it is looks no problem.

Co-authored-by: Sunli <scott_s829@163.com>

This PR makes it so we cancel trials instead of pausing them when they
end with a missing payment method.

Release Notes:

- N/A

Extensions cannot look up available port themselves, hence the new API.
With this I'm able to port our Ruby implementation into an extension.

Release Notes:

- N/A

`ImageItem`'s `file` is returning `""` as its `path` for single-filed
worktrees like the ones are created for the images dropped from the OS.
`ImageItem::load_image_metadata` had used that `path` in FS operations
and the other method tried to use for icon resolving.

Rework the code to use a more specific, `worktree::File` instead and
always use the `abs_path` when dealing with paths from this `file`.

Release Notes:

- Fixed images not opening on drag and drop into the editor

Let's keep https://github.com/zed-industries/zed/pull/30773 and its
complexity out of Zed sources if we can:
https://github.com/rust-lang/rust-analyzer/pull/19814 seems to do a
similar thing and might have fixed the root cause.

If not, we can always reapply this later after ensuring.

Release Notes:

- N/A

Closes #ISSUE

Release Notes:

- N/A

Also pass worktree to the get_dap_binary.

Release Notes:

- N/A

This helps prevent a race condition where the language server would
update in the middle of a `git checkout`

Release Notes:

- N/A

Looks like we missed these when adding the minimap.

Release Notes:

- N/A

Co-authored-by: Kirill Bulatov <mail4score@gmail.com>

This is a follow-up to #30450 so that _global_ `title_bar` configs
shadow _defaults_. The way `SettingsSources::json_merge` works is by
considering non-json-nulls as values to propagate. So it's important
that configs be `Option<T>` so any intent in overriding values is
captured.

This PR follows the same `*Settings<FileContent = *SettingsContent>`
pattern used throughout to keep the `Option`s in the "settings content"
type with the finalized values in the "settings" type.

Release Notes:

- N/A

The image id "image-1" already exists so the id should be "image-4"

Release Notes:

- N/A

Release Notes:

- N/A

---------

Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>

Reverts zed-industries/zed#30812

This PR broke nightly builds on linux by adding an OpenSSL dependency to
the `remote_server` binary, which failed to link when building against
musl.

Release Notes:

- N/A

This PR adds a check for if a Zed Free subscription already exists in
Stripe before we try to create one.

Release Notes:

- N/A

This PR makes it so we create a Zed Free subscription when issuing an
LLM token, if one does not already exist.

Release Notes:

- N/A

---------

Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>

This mostly affects local development. It fixes a bug where we would
only process one Stripe event per polling period (5 seconds) when
hitting old events.

Release Notes:

- N/A

Co-authored-by: Marshall Bowers <git@maxdeviant.com>

This PR makes it so a user can initiate a checkout session for a Zed Pro
trial while on the Zed Free plan.

Release Notes:

- N/A

Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>

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

This PR addresses the following scenario:

1. User's Zed polls for an update, finds one, and installs it
2. User doesn't immediately restart Zed, a new update is released, and
the previous version of Zed would stop polling (ignoring the new update)
3. User eventually restarts Zed and is immediately prompted to install
another update

With this change, the auto-updater will continue polling for and
installing new versions even after an initial update is found, reducing
update prompts on restart.

---

This PR does not address the following scenario:

1. User's Zed polls for an update, finds one, and installs it
2. Another update is released before the next scheduled polling interval
3. User restarts Zed and is immediately prompted to install the newer
update

Release Notes:

- Improved the auto-updater to continue checking for updates even after
finding and installing an initial update. This reduces situations where
users are prompted to install another update immediately after
restarting from a previous update.

Co-authored-by: Ben Kunkle <Ben.kunkle@gmail.com>

This PR adds a sanity check to ensure that we only subscribe the user to
Zed Free if they don't already have an active subscription.

Release Notes:

- N/A

This PR makes the `product` field required in the request body for `POST
/billing/subscriptions`.

We were already passing this everywhere, in practice.

Release Notes:

- N/A

This PR makes it so that when a Stripe subscription is canceled or
paused we'll subscribe the user to Zed Free.

Release Notes:

- N/A

Closes #30555

Release Notes:

- Changed the project diff to autosave the targeted buffer after
resolving a merge conflict.

Problem: In addition to PgUp/PgDown Emacs also binds `Ctrl-V` to page
down and `Meta-V` to page up. These keys wouldn't extend the selection
in Zed.

Reason: Only PageUp/PageDown were assigned to
`editor::SelectPage{Up|Down}` in the `Editor && selection_mode` context.

Solution: In the `Editor && selection_mode` context, bind `Ctrl-V` to
`editor::SelectPageDown` and `Alt-V` to `editor::SelectPageUp`, both in
the mac and linux keymaps.

Release Notes:

- Added to the Emacs keymap bindings for Ctrl/Alt-V in the selection
mode to extend the selection one page up/down

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

Implement tool use handling in Mistral provider, including mapping tool
call events and updating request construction. Add support for
tool_choice and parallel_tool_calls in Mistral API requests.

This works fine with all the existing models. Didn't touched anything
else but for future. Fetching models using their models api, deducting
tool call support, parallel tool calls etc should be done from model
data from api response.

<img width="547" alt="Screenshot 2025-05-06 at 4 52 37 PM"
src="https://github.com/user-attachments/assets/4c08b544-1174-40cc-a40d-522989953448"
/>

Tasks:

- [x] Add tool call support
- [x] Auto Fetch models using mistral api
- [x] Add tests for mistral crates.
- [x] Fix mistral configurations for llm providers.

Release Notes:

- agent: Add tool call support for existing mistral models

---------

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

Precursor to other optimizations, but this already gets us a big
improvement.

Wasm compilation can easily be parallelized, and with all of the cores
on my M4 Max this already gets us an 86% improvement, bringing loading
an extension down to <9ms.

Not all setups will see this much improvement, but it will use the cores
available (it just uses rayon under the hood like we do elsewhere).
Since we load extensions in sequence, this should have a nice impact for
users with a lot of extensions.

#### Before

```
Benchmarking load: Warming up for 3.0000 s
Warning: Unable to complete 100 samples in 5.0s. You may wish to increase target time to 6.5s, or reduce sample count to 70.
load                    time:   [64.859 ms 64.935 ms 65.027 ms]
Found 8 outliers among 100 measurements (8.00%)
  2 (2.00%) low mild
  3 (3.00%) high mild
  3 (3.00%) high severe
```

#### After

```
load                    time:   [8.8685 ms 8.9012 ms 8.9344 ms]
                        change: [-86.347% -86.292% -86.237%] (p = 0.00 < 0.05)
                        Performance has improved.
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild
```

Release Notes:

- N/A

Closes #27642

Currently, the `Open (cmd-o)` action is used to open a local folder
picker when in a local project, and Zed's remote path modal in the case
of a remote project. While this looks intentional, there is now no way
to open a local project when you are in a remote project window. Neither
by shortcut, nor by UI, as the "Open Local Folder" button uses the same
`Open` action.

The reverse is not true, as we already have an `Open Remote
(ctrl-cmd-o)` action to open the remote modal, where you can select "Add
Folder" which opens the same Zed's remote path modal. This already works
in both local and remote window cases.

This PR makes two changes:
1. It changes `Open (cmd-o)` action such that it should always open the
local file picker regardless of which project is currently open, local
or remote. This way we have two non-ambiguios actions `Open` and `Open
Remote`.
2. It also changes the "Open a project" button (which shows up when no
project is open in the project panel) to open the recent modal (which
contains buttons to open either local or remote) instead of choosing on
behalf of the user.

P.S. If we want to open Zed's remote path modal directly, it should be
different action altogether. Not covered for now.

Release Notes:

- Fixed issue where "Open local folder" was not opening folder picker
when connected to a remote host.
- Added `from_existing_connection` flag to `OpenRemote` action to
directly open path picker for current connection, bypassing the Remote
Projects modal.