Closes: https://github.com/zed-industries/zed/discussions/30626
Release Notes:
- Fixed `assistant::QuoteSelection` default shortcuts (`cmd->` and
`ctrl->`) so they work in Agent threads too (in addition to text threads
and in the Editor pane).
Follow-up of https://github.com/zed-industries/zed/pull/19230
Implements the workspace diagnostics pulling, and replaces "pull
diagnostics every open editors' buffer" strategy with "pull changed
buffer's diagnostics" + "schedule workspace diagnostics pull" for the
rest of the diagnostics.
This means that if the server does not support the workspace diagnostics
and does not return more in linked files, only the currently edited
buffer has its diagnostics updated.
This is better than the existing implementation that causes a lot of
diagnostics pulls to be done instead, and we can add more heuristics on
top later for querying more diagnostics.
Release Notes:
- N/A
mostly, I using `git checkout -b branch_name upstream/main` to create
new branch which reference remote upstream not my fork.
When using `Push` will always failed with not permission. So we need
ability to select which remote to push.
Current branch is based on my previous pr #26897
Release Notes:
- Add `PushTo` to select which remote to push.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Follow-up to #24797
This PR ensures some cursor styles do not change for draggable elements
during dragging. The linked PR covered this on the higher level for
draggable divs. However, e.g. the pane divider inbetween two editors is
not a draggable div and thus still has the issue that the cursor style
changes during dragging. This PR fixes this issue by setting the hitbox
to `None` in cases where the element is currently being dragged, which
ensures the cursor style is applied to the cursor no matter what during
dragging.
Namely, this change fixes this for
- non-div pane dividers
- minimap slider and the
- editor scrollbars
and implements it for the UI scrollbars (Notably, UI scrollbars do
already have `cursor_default` on their parent container but would not
keep this during dragging. I opted out on removing this from the parent
containers until #30194 or a similar PR is merged).
https://github.com/user-attachments/assets/f97859dd-5f1d-4449-ab92-c27f2d933c4a
Release Notes:
- N/A
Closes#32205
The issue was that in some places the end of the replacement range used
anchors with `Bias::Left` instead of `Bias::Right`. Before #31872
completions were recomputed on every change and so the anchor bias
didn't matter. After that change, the end anchor didn't move as the
user's typing. Changing it to `Bias::Right` to "stick" to the character
to the right of the cursor fixes this.
Release Notes:
- Fixes incorrect auto-completion of `/files` in text threads (Preview
Only)
Before this I'd get log lines like
> ERROR [project] missing `database_url` setting
Now it's:
> ERROR [project] from extension "Postgres Context Server" version
0.0.3: missing `database_url` setting
Release Notes:
- N/A
The info for `max_tokens` for the model is included in
`{api_url}/models`
I don't think this needs to be `.clamp` like in
`crates/ollama/src/ollama.rs` `get_max_tokens`, but it might need to be
## Before:
Every model shows 2k
## After:
### Json from `{api_url}/models` with model not loaded
```json
{
"id": "qwen2.5-coder-1.5b-instruct-mlx",
"object": "model",
"type": "llm",
"publisher": "lmstudio-community",
"arch": "qwen2",
"compatibility_type": "mlx",
"quantization": "4bit",
"state": "not-loaded",
"max_context_length": 32768
},
```
## Notes
The response from `{api_url}/models` seems to return the `max_tokens`
for the model, not the currently configured context length, but I think
showing the `max_tokens` for the model is better than setting 2k for
everything
`loaded_context_length` exists, but only if the model is loaded at the
startup of zed, which usually isn't the case
maybe `fetch_models` should be rerun when swapping lmstudio models
### Currently configured context
this isn't shown in `{api_url}/models`
### Json from `{api_url}/models` with model loaded
```json
{
"id": "qwen2.5-coder-1.5b-instruct-mlx",
"object": "model",
"type": "llm",
"publisher": "lmstudio-community",
"arch": "qwen2",
"compatibility_type": "mlx",
"quantization": "4bit",
"state": "loaded",
"max_context_length": 32768,
"loaded_context_length": 4096
},
```
Release Notes:
- lmstudio: Fixed showing `max_tokens` in the assistant panel
---------
Co-authored-by: Peter Tripp <peter@zed.dev>
Fixes: #29812Fixes: #22538
Co-Authored-By: <corentinhenry@gmail.com>
Release Notes:
- vim: Multi-key bindings in insert mode will now show the pending
keystroke in the buffer. For example if you have `jk` mapped to escape,
pressing `j` will immediately show a `j`.
This pull request updates the documentation for the debugger to include
Go-specific examples alongside existing Python examples.
Documentation update:
*
[`docs/src/debugger.md`](diffhunk://#diff-aa14715cca56f3ad6a32c669b0c317250dab212b8108136b7ca79217465f39b8R69-R80):
Added a new "Go examples" section with a JSON snippet demonstrating how
to configure the debugger for Go using Delve.
Release Notes:
- debugger: Add Go debugging example to debugger documentation
---------
Co-authored-by: Cole Miller <cole@zed.dev>
This was a regression with my recent fixes to pinned tabs. Dragging a
pinned tab left in the pinned region would still update the pinned tab
count, which would later cause an out-of-bounds later when it used that
value to index into a vec.
https://zed-industries.slack.com/archives/C04S6T1T7TQ/p1749220447796559
Release Notes:
- Fixed a panic caused by dragging a pinned item to the left in the
pinned region
Allows setting element as window control elements which consist of
`Drag`, `Close`, `Max`, or `Min`. This allows you to implement
dynamically sized elements that control the platform window, this is
used for areas such as the title bar. Currently only implemented for
Windows.
Release Notes:
- N/A
Release Notes:
- N/A
---
This change is used to solve the problem of not being able to respond
correctly in two-layer scrolling (in different directions). This is a
common practical requirement.
As in the example, in actual use, there may be a scene with a horizontal
scroll in a vertical scroll. Before the modification, if we scroll up
and down in the area that can scroll horizontally, it will not respond
(because it is blocked by the horizontal scroll layer).
## Before
https://github.com/user-attachments/assets/e8ea0118-52a5-44d8-b419-639d4b6c0793
## After
https://github.com/user-attachments/assets/aa14ddd7-5596-4dc5-9c6e-278aabdfef8e
----
This change may cause many side effects, causing some scrolling details
to be different from before, and more testing and analysis are needed.
I have tested some existing scenarios of Zed (such as opening the Branch
panel on the Editor and scrolling) and it seems to be correct (but it is
possible that I don’t know some interaction details). Here, the person
who added this line of code before needs to evaluate the original
purpose.
The `async-watch` crate doesn't seem to be maintained and we noticed
several panics coming from it, such as:
```
[bug] failed to observe change after notificaton.
zed::reliability::init_panic_hook::{{closure}}::hea8cdcb6299fad6b+154543526
std::panicking::rust_panic_with_hook::h33b18b24045abff4+127578547
std::panicking::begin_panic_handler::{{closure}}::hf8313cc2fd0126bc+127577770
std::sys::backtrace::__rust_end_short_backtrace::h57fe07c8aea5c98a+127571385
__rustc[95feac21a9532783]::rust_begin_unwind+127576909
core::panicking::panic_fmt::hd54fb667be51beea+9433328
core::option::expect_failed::h8456634a3dada3e4+9433291
assistant_tools::edit_agent::EditAgent::apply_edit_chunks::{{closure}}::habe2e1a32b267fd4+26921553
gpui::app::async_context::AsyncApp::spawn::{{closure}}::h12f5f25757f572ea+25923441
async_task::raw::RawTask<F,T,S,M>::run::h3cca0d402690ccba+25186815
<gpui::platform::linux::x11::client::X11Client as gpui::platform::linux::platform::LinuxClient>::run::h26264aefbcfbc14b+73961666
gpui::platform::linux::platform::<impl gpui::platform::Platform for P>::run::hb12dcd4abad715b5+73562509
gpui::app::Application::run::h0f936a5f855a3f9f+150676820
zed::main::ha17f9a25fe257d35+154788471
std::sys::backtrace::__rust_begin_short_backtrace::h1edd02429370b2bd+154624579
std::rt::lang_start::{{closure}}::h3d2e300f10059b0a+154264777
std::rt::lang_start_internal::h418648f91f5be3a1+127502049
main+154806636
__libc_start_main+46051972301573
_start+12358494
```
I didn't find an executor-agnostic watch crate that was well maintained
(we already tried postage and async-watch), so decided to implement it
our own version.
Release Notes:
- Fixed a panic that could sometimes occur when the agent performed
edits.
This changes the context server crate so that the input/output for a
request are encoded at the type level, similar to how it is done for LSP
requests.
This also makes it easier to write tests that mock context servers, e.g.
you can write something like this now when using the `test-support`
feature of the `context-server` crate:
```rust
create_fake_transport("mcp-1", cx.background_executor())
.on_request::<context_server::types::request::PromptsList>(|_params| {
PromptsListResponse {
prompts: vec![/* some prompts */],
..
}
})
```
Release Notes:
- N/A
I don't want to fetch `--all` branch, we should can picker which remote
to fetch.
Release Notes:
- Added the `git::FetchFrom` action to fetch from a single remote.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Closes#27596
The problem in this case was incorrect identification of which language
(layer) contains the selection.
Language layer selection incorrectly assumed that the deepest
`SyntaxLayer` containing a range was the most specific. This worked for
Markdown (base document + injected subtrees) but failed for PHP, where
`injection.combined` injections are used to make HTML logically function
as the base layer, despite being at a greater depth in the layer stack.
This caused HTML to be incorrectly identified as the most specific
language for PHP ranges.
The solution is to track included sub-ranges for syntax layers and
filter out layers that don't contain a sub-range covering the desired
range. The top-level layer is never filtered to ensure gaps between
sibling nodes always have a fallback language, as the top-level layer is
likely more correct than the default language settings.
Release Notes:
- Fixed an issue in PHP where PHP language settings would be
occasionally overridden by HTML language settings
Follow-up of https://github.com/zed-industries/zed/pull/19230
* starts to send `result_id` in pull requests to allow servers to reply
with non-full results
* fixes a bug where disk-based diagnostics were offset after pulling the
diagnostics
* fixes a bug due to which pull diagnostics could not be disabled
* uses better names and comments for the workspace pull diagnostics part
Release Notes:
- N/A
This is a small PR that adds a `.jsdoc` scope to JSDoc tokens, just like
[JSX](3fdbc3090d/crates/languages/src/javascript/highlights.scm (L239))
has a specific scope.
This effectively allows differentiating between JavaScript keywords and
JSDoc tags in comments.
Release Notes:
- Add scope for JSDoc
Part of #28238
This PR refactors `FindHyperlink` handling and associated code in
`terminal.rs` into its own file for improved testability, and adds
tests.
Release Notes:
- N/A
This allows storing the profile per thread, as well as moving the logic
of which tools are enabled or not to the profile itself.
This makes it much easier to switch between profiles, means there is
less global state being changed on every profile change.
Release Notes:
- agent panel: allow saving the profile per thread
---------
Co-authored-by: Ben Kunkle <ben.kunkle@gmail.com>
A minor refactor ~needed to unblock #22546; it's pretty hard to add an
extra field to `diff_transforms` dimension, as it is a 2-tuple (which
uses a blanket impl)
Release Notes:
- N/A
Fixes rendering of colors in the terminal to use XTerm's idiosyncratic standard steps instead of the range that was previously in use. Matches the behavior of Alacritty, Ghostty, iTerm2, and every other terminal emulator I've looked at.
Release Notes:
- Fixed rendering of terminal colors for the XTerm 256-color indexed color palette.
This PR fixes some broken links that where found using
[lychee](https://github.com/lycheeverse/lychee/) as discussed today with
@JosephTLyons and @nathansobo at the RustNL hackathon. Using
[lychee-action](https://github.com/lycheeverse/lychee-action/) we can
scan for broken links daily to prevent issues in the future.
There are still 6 broken links that I didn't know how to fix myself.
See https://github.com/thomas-zahner/zed/actions/runs/15075808232 for
details.
## Missing images
```
Errors in ./docs/src/channels.md
[ERROR] file:///home/runner/work/zed/zed/docs/.gitbook/assets/channels-3.png | Cannot find file
[ERROR] file:///home/runner/work/zed/zed/docs/.gitbook/assets/channels-1.png | Cannot find file
[ERROR] file:///home/runner/work/zed/zed/docs/.gitbook/assets/channels-2.png | Cannot find file
```
These errors are showing up as missing images on
https://zed.dev/docs/channels
I tried to search the git history to see when or why they were deleted
but didn't find anything.
## ./crates/assistant_tools/src/edit_agent/evals/fixtures/zode/prompt.md
There are three errors in that file. I don't fully understand how these
issues were caused historically. Technically it would be possible to
ignore the files but of course if possible we should address the issues.
Release Notes:
- N/A
---------
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes#31491
### Problem
Mistral API enforces strict conversation flow requirements that other
providers don't. Specifically, after a `tool` message, the next message
**must** be from the `assistant` role, not `user`. This causes the
error:
```
"Unexpected role 'user' after role 'tool'"
```
This can also occur in normal conversation flow where mistral doesn't
return the assistant message but that is something which can't be
reproduce reliably.
### Root Cause
When users interrupt an ongoing tool call sequence by sending a new
message, we insert a `user` message directly after a `tool` message,
violating Mistral's protocol.
**Expected Mistral flow:**
```
user → assistant (with tool_calls) → tool (results) → assistant (processes results) → user (next input)
```
**What we were doing:**
```
user → assistant (with tool_calls) → tool (results) → user (interruption) ❌
```
### Solution
Insert an empty `assistant` message between any `tool` → `user` sequence
in the Mistral provider's request construction. This satisfies Mistral's
API requirements without affecting other providers or requiring UX
changes.
### Testing
To reproduce the original error:
1. Start agent chat with `codestral-latest`
2. Send: "Describe this project using tool call only"
3. Once tool calls begin, send: "stop this"
4. Main branch: API error
5. This fix: Works correctly
Release Notes:
- Fixed Mistral tool calling in some cases
Ideally we would show multi-keystroke binding, but I'd say this improves
over the status quo.
A partial solution to #27334
Release Notes:
- Fixed spurious warning for lack of edit prediction on multi-keystroke
binding
Co-authored-by: Ben Kunkle <ben@zed.dev>
Now immediately initializes the zlog filter even when there isn't an env
config. Before this change the default filters were applied after
settings load - I was seeing some `zbus` logs on init.
Also defaults to allowing warnings and errors from the suppressed log
sources. If these turn out to be chatty (they don't seem to be so far),
can bring back more suppression.
Release Notes:
- N/A
Fixes two things:
* ~3 months ago [in PR
#26420](https://github.com/zed-industries/zed/pull/26420/files#diff-33b58aa2da03d791c2c4761af6012851b7400e348922d64babe5fd48ac2a8e60)
`bindings_for_action` was changed to return bindings even when they are
shadowed (when the keystrokes would actually do something else).
* For edit prediction keybindings there was some odd behavior where
bindings for `edit_prediction_conflict` were taking precedence over
bindings for `edit_prediction` even when the `edit_prediction_conflict`
predicate didn't match. The workaround for this was #24812. The way it
worked was:
- List all bindings for the action
- For each binding, get the highest precedence binding with the same
input sequence
- If the highest precedence binding has the same action, include this
binding. This was the bug - this meant that if a binding in the keymap
has the same keystrokes and action it can incorrectly take display
precedence even if its context predicate does not pass.
- Fix is to check that the highest precedence binding is a full match.
To do this efficiently, it's based on an index within the keymap
bindings.
Also adds `highest_precedence_binding_*` variants which avoid the
inefficiency of building lists of bindings just to use the last.
Release Notes:
- Fixed display of keybindings to skip bindings that are shadowed by a
binding that uses the same keystrokes.
- Fixed display of `editor::AcceptEditPrediction` bindings to use the
normal precedence that prioritizes user bindings.
Cleaner to have references to this be `toast::RunAction` matching how it
appears in the keymap, instead of `workspace::RunAction`.
Release Notes:
- N/A
