Release Notes:

- N/A

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

Release Notes:

- Switched to "standard" as a default line height in the terminal

Closes #ISSUE

Release Notes:

- N/A

---------

Co-authored-by: Katie Geer <katie@zed.dev>
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Co-authored-by: David Kleingeld <davidsk@zed.dev>

Release Notes:

- N/A

Release Notes:

- N/A

---------

Co-authored-by: Anthony <hello@anthonyeid.me>
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Anthony <anthony@zed.dev>
Co-authored-by: Ben Kunkle <ben.kunkle@gmail.com>

Just making it more consistent with other pickers—button actions
justified to the right and timestamp directly in the list item to avoid
as much as possible relevant information tucked away in a tooltip where
using the keyboard will mostly be the main mean of interaction.

<img width="500" height="310" alt="Screenshot 2025-09-24 at 10  41@2x"
src="https://github.com/user-attachments/assets/0bd478da-d1a6-48fe-ade7-a4759d175c60"
/>


Release Notes:

- N/A

Split up provider, prediction, and global into modules.

Release Notes:

- N/A

The new cloud endpoint returns structured edits, but they may include
more of the input excerpt than what we want to display in the preview,
so we compute a smaller diff on the client side against the snapshot.

Release Notes:

- N/A

This reduces the size of cursor by a usize when the summary does not
require a context making Cursor usages and constructions slightly more
efficient.

This change is a bit annoying though, as Rust has no means of
specializing, so this uses a `ContextlessSummary` trait with a blanket
impl while turning the `Context` into a GAT `Context<'a>`. This means
`Summary` implies are a bit more verbose now while contextless ones are
slimmer. It does come with the downside that the lifetime in the GAT is
always considered invariant, so some lifetime splitting occurred due to
that.


 ```
push/4096               time:   [352.65 µs 360.87 µs 367.80 µs]
                        thrpt:  [10.621 MiB/s 10.825 MiB/s 11.077 MiB/s]
                 change:
time: [-2.6633% -1.3640% -0.0561%] (p = 0.05 < 0.05)
                        thrpt:  [+0.0561% +1.3828% +2.7361%]
                        Change within noise threshold.
Found 16 outliers among 100 measurements (16.00%)
  7 (7.00%) low severe
  3 (3.00%) low mild
  2 (2.00%) high mild
  4 (4.00%) high severe
push/65536              time:   [1.2917 ms 1.2949 ms 1.2979 ms]
                        thrpt:  [48.156 MiB/s 48.267 MiB/s 48.387 MiB/s]
                 change:
time: [+1.4428% +1.9844% +2.5299%] (p = 0.00 < 0.05)
                        thrpt:  [-2.4675% -1.9458% -1.4223%]
                        Performance has regressed.
Found 3 outliers among 100 measurements (3.00%)
  1 (1.00%) low severe
  1 (1.00%) low mild
  1 (1.00%) high severe

append/4096             time:   [677.87 ns 678.87 ns 679.83 ns]
                        thrpt:  [5.6112 GiB/s 5.6192 GiB/s 5.6274 GiB/s]
                 change:
time: [-0.8924% -0.5017% -0.1705%] (p = 0.00 < 0.05)
                        thrpt:  [+0.1708% +0.5043% +0.9004%]
                        Change within noise threshold.
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) low mild
  1 (1.00%) high mild
append/65536            time:   [9.3275 µs 9.3406 µs 9.3536 µs]
                        thrpt:  [6.5253 GiB/s 6.5344 GiB/s 6.5435 GiB/s]
                 change:
time: [+0.5409% +0.7215% +0.9054%] (p = 0.00 < 0.05)
                        thrpt:  [-0.8973% -0.7163% -0.5380%]
                        Change within noise threshold.

slice/4096              time:   [27.673 µs 27.791 µs 27.907 µs]
                        thrpt:  [139.97 MiB/s 140.56 MiB/s 141.16 MiB/s]
                 change:
time: [-1.1065% -0.6725% -0.2429%] (p = 0.00 < 0.05)
                        thrpt:  [+0.2435% +0.6770% +1.1189%]
                        Change within noise threshold.
Found 5 outliers among 100 measurements (5.00%)
  4 (4.00%) low mild
  1 (1.00%) high mild
slice/65536             time:   [507.55 µs 517.40 µs 535.60 µs]
                        thrpt:  [116.69 MiB/s 120.80 MiB/s 123.14 MiB/s]
                 change:
time: [-1.3489% +0.0599% +2.2591%] (p = 0.96 > 0.05)
                        thrpt:  [-2.2092% -0.0598% +1.3674%]
                        No change in performance detected.
Found 8 outliers among 100 measurements (8.00%)
  5 (5.00%) low mild
  2 (2.00%) high mild
  1 (1.00%) high severe

bytes_in_range/4096     time:   [3.3917 µs 3.4108 µs 3.4313 µs]
                        thrpt:  [1.1117 GiB/s 1.1184 GiB/s 1.1247 GiB/s]
                 change:
time: [-5.3466% -4.7193% -4.1262%] (p = 0.00 < 0.05)
                        thrpt:  [+4.3038% +4.9531% +5.6487%]
                        Performance has improved.
Found 6 outliers among 100 measurements (6.00%)
  1 (1.00%) low mild
  5 (5.00%) high mild
bytes_in_range/65536    time:   [88.175 µs 88.613 µs 89.111 µs]
                        thrpt:  [701.37 MiB/s 705.31 MiB/s 708.82 MiB/s]
                 change:
time: [-0.6935% +0.3769% +1.4655%] (p = 0.50 > 0.05)
                        thrpt:  [-1.4443% -0.3755% +0.6984%]
                        No change in performance detected.
Found 2 outliers among 100 measurements (2.00%)
  2 (2.00%) high mild

chars/4096              time:   [678.70 ns 680.38 ns 682.08 ns]
                        thrpt:  [5.5927 GiB/s 5.6067 GiB/s 5.6206 GiB/s]
                 change:
time: [-0.6969% -0.2755% +0.1485%] (p = 0.20 > 0.05)
                        thrpt:  [-0.1483% +0.2763% +0.7018%]
                        No change in performance detected.
Found 9 outliers among 100 measurements (9.00%)
  5 (5.00%) low mild
  4 (4.00%) high mild
chars/65536             time:   [12.720 µs 12.775 µs 12.830 µs]
                        thrpt:  [4.7573 GiB/s 4.7778 GiB/s 4.7983 GiB/s]
                 change:
time: [-0.6172% -0.1110% +0.4179%] (p = 0.68 > 0.05)
                        thrpt:  [-0.4162% +0.1112% +0.6211%]
                        No change in performance detected.
Found 2 outliers among 100 measurements (2.00%)
  1 (1.00%) low mild
  1 (1.00%) high mild

clip_point/4096         time:   [33.240 µs 33.310 µs 33.394 µs]
                        thrpt:  [116.98 MiB/s 117.27 MiB/s 117.52 MiB/s]
                 change:
time: [-2.8892% -2.6305% -2.3438%] (p = 0.00 < 0.05)
                        thrpt:  [+2.4000% +2.7015% +2.9751%]
                        Performance has improved.
Found 12 outliers among 100 measurements (12.00%)
  1 (1.00%) low mild
  4 (4.00%) high mild
  7 (7.00%) high severe
clip_point/65536        time:   [1.6531 ms 1.6586 ms 1.6640 ms]
                        thrpt:  [37.560 MiB/s 37.683 MiB/s 37.808 MiB/s]
                 change:
time: [-6.6381% -5.9395% -5.2680%] (p = 0.00 < 0.05)
                        thrpt:  [+5.5610% +6.3146% +7.1100%]
                        Performance has improved.
Found 7 outliers among 100 measurements (7.00%)
  1 (1.00%) low mild
  2 (2.00%) high mild
  4 (4.00%) high severe

point_to_offset/4096    time:   [11.586 µs 11.603 µs 11.621 µs]
                        thrpt:  [336.15 MiB/s 336.67 MiB/s 337.16 MiB/s]
                 change:
time: [-14.289% -14.111% -13.939%] (p = 0.00 < 0.05)
                        thrpt:  [+16.197% +16.429% +16.672%]
                        Performance has improved.
Found 12 outliers among 100 measurements (12.00%)
  3 (3.00%) low severe
  5 (5.00%) low mild
  4 (4.00%) high mild
point_to_offset/65536   time:   [527.74 µs 532.08 µs 536.51 µs]
                        thrpt:  [116.49 MiB/s 117.46 MiB/s 118.43 MiB/s]
                 change:
time: [-6.7825% -4.6235% -2.3533%] (p = 0.00 < 0.05)
                        thrpt:  [+2.4100% +4.8477% +7.2760%]
                        Performance has improved.
Found 8 outliers among 100 measurements (8.00%)
  4 (4.00%) high mild
  4 (4.00%) high severe

cursor/4096             time:   [16.154 µs 16.192 µs 16.232 µs]
                        thrpt:  [240.66 MiB/s 241.24 MiB/s 241.81 MiB/s]
                 change:
time: [-3.2536% -2.9145% -2.5526%] (p = 0.00 < 0.05)
                        thrpt:  [+2.6194% +3.0019% +3.3630%]
                        Performance has improved.
Found 5 outliers among 100 measurements (5.00%)
  1 (1.00%) low mild
  2 (2.00%) high mild
  2 (2.00%) high severe
cursor/65536            time:   [509.60 µs 511.24 µs 512.93 µs]
                        thrpt:  [121.85 MiB/s 122.25 MiB/s 122.65 MiB/s]
                 change:
time: [-7.3677% -6.6017% -5.7840%] (p = 0.00 < 0.05)
                        thrpt:  [+6.1391% +7.0683% +7.9537%]
                        Performance has improved.
Found 6 outliers among 100 measurements (6.00%)
  3 (3.00%) high mild
  3 (3.00%) high severe
```
Release Notes:

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

In some rare cases, the auto-generated block gets stuck in
`.git/info/exclude`. We now auto-clean it.

Closes #38374

Release Notes:

- Remove auto-generated block from git excludes if it gets stuck there.

Related to #38427

Release Notes:

* N/A

Fixes ZED-1K3

Release Notes:

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

The `Duration` argument in `get_models` has been unused for over a year.

The `complete` function is also unused and it has fallen behind in new
feature additions such as Authorization support. This used to exist
because ollama didn't support tools in streaming mode, `with_tools` also
existed because of that. Now however there is no reason to keep this
around.

`ChatResponseDelta ` had unnecessary `#[allow(unused)]` macros since the
fields are marked `pub`. Using `#[expect(unused)]` would've caught this.

Release Notes:

- N/A

Not an ideal fix, but a proper one will require restructuring the
iterator state (which would be easier if Rust had first class
generators)
Fixes ZED-1MB

Release Notes:

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

Release Notes:

- N/A

Confusing to have these interspersed with the streaming request types

Release Notes:

- N/A

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

Release Notes:

- Reverted the ability to show/hide the titlebar. This caused rendering
bugs on
macOS, and we're preparing for the redesign which requires the toolbar
being present.

---------

Co-authored-by: Kirill Bulatov <kirill@zed.dev>

Closes #38576

In case of inline element rendering, we can have multiple text runs on
the same display row. There was a bug in
https://github.com/zed-industries/zed/pull/37165 which doesn't consider
this multiple text runs case. This PR fixes that and adds a test for it.

Before:

<img width="600" alt="image"
src="https://github.com/user-attachments/assets/3bdf5f14-988b-45dc-bc8e-c5d61ab35a93"
/>

After:

<img width="600" alt="image"
src="https://github.com/user-attachments/assets/0e1a45ff-c521-4994-b259-3a054d89c4df"
/>

Release Notes:

- Fixed an issue where text could be incorrectly highlighted during
search when a line contained an inline color preview.

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

In the agent panel's `thread_view.rs` file, we have a `render_tool_call`
function that controls what we show in the UI for most types of tools.
However, for some of them—for example, terminal/execute and edit
tools—we have a special rendering so we can tailor the UI for their
specific needs. But... before the specific rendering function is called,
all tools still go through the `render_tool_call`.

Problem is that, in the case of the terminal tool, you couldn't see the
full command the agent wants to run when the tool is still in its
`render_tool_call` state. That's mostly because of the treatment we give
to labels while in that state. A particularly bad scenario because
well... seeing the _full_ command _before_ you choose to accept or
reject is rather important.

This PR fixes that by essentially special-casing the terminal tool
display when in the `render_tool_call` rendering state, so to speak.
There's still a slight UI misalignment I want to fix but it shouldn't
block this fix to go out.

Here's our final result:

<img width="400" height="1172" alt="Screenshot 2025-09-23 at 6  19@2x"
src="https://github.com/user-attachments/assets/71c79e45-ab66-4102-b046-950f137fa3ea"
/>

Release Notes:

- agent: Fixed terminal command not being fully displayed while in the
"waiting for confirmation" state.

Closes #31561

Release Notes:

- Implemented the select_regex Helix keymap

Prior: The keymap `s` defaulted to `vim::Substitute`

After:
<img width="1387" height="376" alt="image"
src="https://github.com/user-attachments/assets/4d3181d9-9d3f-40d2-890f-022655c77577"
/>

Thank you to @ConradIrwin for pairing to work on this

This PR removes the experimental jj bookmark picker that was added in
#30883.

This was just an exploratory prototype and while I would like to have
native jj UI at some point, I don't know when we'll get back to it.

Release Notes:

- N/A

Move happened in #38718

Release Notes:

- N/A

Follow-up of https://github.com/zed-industries/zed/pull/32816
Closes https://github.com/zed-industries/zed/issues/38602


https://github.com/user-attachments/assets/26058c91-4ffd-4c6f-a41d-17da0c3d7220

Release Notes:

- Fixed buffer colors not cleared on empty LSP responses

Release Notes:

- N/A

Closes: https://github.com/zed-industries/zed/issues/38525
Documentation follow up for #38614

Task filtering behavior is currently undocumented.

Release Notes:

- N/A

---------

Co-authored-by: Copilot <175728472+Copilot@users.noreply.github.com>
Co-authored-by: Kirill Bulatov <mail4score@gmail.com>

Release Notes:

- N/A

Co-authored-by: Michael Sloan <mgsloan@gmail.com>

Closes #30678

This is caused by `TerminalOutput::full_text` triming trailing newline
when creating the "REPL Output" buffer.

Release Notes:

- fix: Preserve trailing newline in `TerminalOutput::full_text`

Release Notes:

- N/A

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

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

- Previously fixed by: https://github.com/zed-industries/zed/pull/36712
- Regressed in: https://github.com/zed-industries/zed/pull/36572

Release Notes:

- N/A

Release Notes:

- N/A

---------

Co-authored-by: David Kleingeld <davidsk@zed.dev>

The current problem is that if I specify model parameters, like
`max_tokens`, in `settings.json` for an Ollama model, they do not
override the values coming from the Ollama API. Instead, the parameters
from the API are used. For example, in the settings below, even though I
have overridden `max_tokens`, Zed will still use the API's default
`context_length` of 4k.

```
  "language_models": {
    "ollama": {
      "available_models": [
        {
          "name": "qwen3-coder:latest",
          "display_name": "Qwen 3 Coder",
          "max_tokens": 64000,
          "supports_tools": true,
          "keep_alive": "15m",
          "supports_thinking": false,
          "supports_images": false
        }
      ]
    }
  },
```

Release Notes:

- Fixed an issue where Ollama model parameters were not being correctly
overridden by user settings.

Release Notes:

- N/A

---------

Co-authored-by: Julia <julia@zed.dev>

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

Release Notes:

- N/A

Release Notes:

- N/A

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

Mostly just breaking a massive wall of text in small paragraphs for ease
of reading/parsing.

Release Notes:

- N/A

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

Previously, every piece of text in the agent panel was controlled by
`agent_font_size`. Although it is nice to only have one setting to tweak
that, it could be a bit misleading particularly because we use
monospaced and sans-serif fonts for different elements in the panel. Any
editor/textarea in the panel, whehter it is the main message editor or
the previous message editor, uses the buffer font. Therefore, I think it
is reasonable to expect that tweaking `buffer_font_size` would also
change the agent panel's usage of buffer fonts.

With this change, regular buffers and the agent panel's message editor
will always have the same size.

Release Notes:

- agent: Made the agent panel's textarea font size follow the font size
of regular buffers. They're now both controlled by the
`buffer_font_size` setting.

Address an issue where, in Vim mode, clicking past the end of a line
after selecting the entire line would place the cursor on the newline
character instead of the last character of the line, which is
inconsistent with Vim's normal mode expectations.

I believe the root cause was that the cursor’s position was updated to
the end of the line before the mode switch from Visual to Normal, at
which point `DisplayMap.clip_at_line_ends` was still set to `false`. As
a result, the cursor could end up in an invalid position for Normal
mode. The fix ensures that when switching between these two modes, and
if the selection is empty, the selection point is properly clipped,
preventing the cursor from being placed past the end of the line.

Related #38049 

Release Notes:

- Fixed issue in Vim mode where switching from any mode to normal mode
could end up with the cursor in the newline character

---------

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

Nowadays, people don't expect @-mentioning a directory to include the
contents of all files within it. Doing so makes it very likely to
consume an undesirable amount of tokens.

By default, we'll now only include the path of the directory and let the
model decide how much to read via tools. We'll still include the
contents if no tools are available (e.g. "Minimal" profile is selected).

Release Notes:

- Agent Panel: Do not include the content of @-mentioned directories
when tools are available

The edit prediction debug tools has been renamed to zeta2 inspector
because it's now zeta specific. It will now always display the last
prediction request context, prompt, and model response.

Release Notes:

- N/A

---------

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

Closes #38651 

`git_panel.set_amend_pending(false, cx);` was being called before
`git_panel.commit_changes(...)` which was causing the commit buffer to
be cleared/reset before actually sending the commit request to git.

Introduced by #35268 which added clear buffer functionality to the
`set_amend_pending` function.

Release Notes:

- Fix git amend on panel sending "Update ..." instead of the original
commit message
- FIx git amend button not working

Release Notes:

- N/A

Release Notes:

- Added "show_summary" & "show_command" settings to the initial
tasks.json file.


This makes the initial task template match the docs here:
https://zed.dev/docs/tasks

Solves an issue where Google APIs refuse all requests with file-based
tool calls attached.
This seems to get triggered in the case where:

- copy_path + another file-based tool call is enabled
- default terminal is `/bin/bash` or something similar

It is unclear why this is happening, but removing the terminal commands
in those tool calls seems to have solved the issue.

Closes #37180 and #37414

Release Notes:

- agent: Fix Gemini refusing requests with certain profiles/systems.

## Problem

Zed was crashing with a UTF-8 character boundary error when rendering
text containing multi-byte characters (like emojis or CJK characters):

```
Thread "main" panicked with "byte index 49 is not a char boundary; it is inside '…' (bytes 48..51)"
```

## Root Cause Analysis

The PR reviewer correctly identified that the issue was not in the
DirectWrite boundary handling, but rather in the text run length
calculation in the text system. When text runs are split across lines in
`text_system.rs:426`, the calculation:

```rust
let run_len_within_line = cmp::min(line_end, run_start + run.len) - run_start;
```

This could result in `run_len_within_line` values that don't respect
UTF-8 character boundaries, especially when multi-byte characters (like
'…' which is 3 bytes) get split across lines. The resulting `FontRun`
objects would have lengths that don't align with character boundaries,
causing the panic when DirectWrite tries to slice the string.

## Solution

Fixed the issue by adding UTF-8 character boundary validation in the
text system where run lengths are calculated. The fix ensures that when
text runs are split across lines, the split always occurs at valid UTF-8
character boundaries:

```rust
// Ensure the run length respects UTF-8 character boundaries
if run_len_within_line > 0 {
    let text_slice = &line_text[run_start - line_start..];
    if run_len_within_line < text_slice.len() && !text_slice.is_char_boundary(run_len_within_line) {
        // Find the previous character boundary using efficient bit-level checking
        // UTF-8 characters are at most 4 bytes, so we only need to check up to 3 bytes back
        let lower_bound = run_len_within_line.saturating_sub(3);
        let search_range = &text_slice.as_bytes()[lower_bound..=run_len_within_line];
        
        // SAFETY: A valid character boundary must exist in this range because:
        // 1. run_len_within_line is a valid position in the string slice
        // 2. UTF-8 characters are at most 4 bytes, so some boundary exists in [run_len_within_line-3..=run_len_within_line]
        let pos_from_lower = unsafe {
            search_range
                .iter()
                .rposition(|&b| (b as i8) >= -0x40)
                .unwrap_unchecked()
        };
        
        run_len_within_line = lower_bound + pos_from_lower;
    }
}
```

## Testing

- ✅ Builds successfully on all platforms
- ✅ Eliminates UTF-8 character boundary panics
- ✅ Maintains existing functionality for all text types
- ✅ Handles edge cases like very long multi-byte characters

## Benefits

1. **Root cause fix**: Addresses the issue at the source rather than
treating symptoms
2. **Performance optimal**: Uses the same efficient algorithm as the
standard library
3. **Minimal changes**: Only modifies the specific problematic code path
4. **Future compatible**: Can be easily replaced with
`str::floor_char_boundary()` when stabilized

## Alternative Approaches Considered

1. **DirectWrite boundary fixing**: Initially tried to fix in
DirectWrite, but this was treating symptoms rather than the root cause
2. **Helper function approach**: Considered extracting to a helper
function, but inlined implementation is more appropriate for this
specific use case
3. **Standard library methods**: `floor_char_boundary()` is not yet
stable, so implemented equivalent logic

The chosen approach provides the best balance of performance, safety,
and code maintainability.
---
Release Notes:

- N/A

Closes
https://github.com/zed-industries/zed/issues/6730#issuecomment-3320933701

That way if multiple servers are running while reporting the same
results we prevent opening multi buffers for single entries.

Release Notes:

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

Add tests on task commands, to ensure things like
https://github.com/zed-industries/zed/issues/38343 do not come so easily
unnoticed and to provide a base to create more tests in the future, if
needed.

Release Notes:

- N/A

---------

Co-authored-by: Lukas Wirth <lukas@zed.dev>

Closed #33759
Closed #38166

### Summary

This PR fixes the way `go test` commands are generated for **testify
suite test methods**.
Previously, only the method name was included in the `-run` flag, which
caused Go’s test runner to fail to find suite test cases.

---

### Problem


https://github.com/user-attachments/assets/e6f80a77-bcf3-457c-8bfb-a7286d44ff71

1. **Incorrect command** was generated for suite tests:

   ```bash
   go test -run TestSomething_Success
   ```

   This results in:

   ```
   testing: warning: no tests to run
   ```

2. The correct format requires the **suite name + method name**:

   ```bash
   go test -run ^TestFooSuite$/TestSomething_Success$
   ```

Without the suite prefix (`TestFooSuite`), Go cannot locate test methods
defined on a suite struct.

---

### Changes Made

* **Updated `runnables.scm`**:

  * Added a new query rule for suite methods (`.*Suite` receiver types).
* Ensures only methods on suite structs (e.g., `FooSuite`) are matched.
  * Tagged these with `go-testify-suite` in addition to `go-test`.

* **Extended task template generation**:

  * Introduced `GO_SUITE_NAME_TASK_VARIABLE` to capture the suite name.
  * Create a `TaskTemplate` for the testify suite.

* **Improved labeling**:

* Labels now show the full path (`go test ./pkg -v -run
TestFooSuite/TestSomething_Success`) for clarity.

* **Added a test** `test_testify_suite_detection`:

* Covered testify suite cases to ensure correct detection and command
generation.

---

### Impact


https://github.com/user-attachments/assets/ef509183-534a-4aa4-9dc7-01402ac32260

* **Before**: Running a suite test method produced “no tests to run.”
* **After**: Suite test methods are runnable individually with the
correct `-run` command, and full suites can still be executed as before.

### Release Notes

* Fixed generation of `go test` commands for **testify suite test
methods**.
Suite methods now include both the suite name and the method name in the
`-run` flag (e.g., `^TestFooSuite$/TestSomething_Success$`), ensuring
they are properly detected and runnable individually.

Buffer search initiates a new search every time a key is pressed in the
buffer search bar. This would cancel the task associated with any
pending searches. Whenever one of these searches was canceled Zed would
log `[search]: oneshot canceled`. This log would trigger almost on every
keypress when typing moderately fast. This PR silences these logs by not
treating canceled searches as errors.

Release Notes:

- N/A

Reorder the shortcuts for `pane::GoForward` so the menu now shows
`Alt-=` instead of `forward`

Release Notes:

- N/A

I noticed that after we paste in line mode, the cursor position is
positioned at the beginning of the next logical line which is somewhat
undesirable since then inserting/appending will position the cursor
after the selection. This does not match helix behaviour which we should
further investigate.

Follow-up to https://github.com/zed-industries/zed/pull/38663

Release Notes:

- N/A