Release Notes:
- Added Codestral edit predictions provider which can be enabled by adding an API key in the Mistral section of agent settings.
## Config
Get API key from https://console.mistral.ai/codestral and add it in the Mistral section of the agent settings.
```
"features": {
"edit_prediction_provider": "codestral"
},
"edit_predictions": {
"codestral": {
"model": "codestral-latest",
"max_tokens": 150
}
},
```
---------
Co-authored-by: Michael Sloan <michael@zed.dev>
Closes#5355
Release Notes:
- Fixed rendering glitches with files with more than 16 million lines
(that occured due to floating number rounding errors).
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
This PR is a follow-up to #39090 and addresses two issues:
* Moves `conpty.dll` and `OpenConsole.exe` out of the `bin` folder to
prevent other programs from using them.
* Updates these files only after Zed exits, avoiding update failures due
to file locks.
Release Notes:
- N/A
---------
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
Closes#22657Closes#37863
# Background
Several users have noted that the terminal shipped with Zed on Windows
is either misbehaving or missing several features including lack of
consistent clearing behaviour. After some investigation which included
digging into the Microsoft Terminal project and VSCode editor, it turns
out that the pseudoconsole provided by Windows OS is severely outdated
which manifests itself in problems such as lack of clearing behaviour,
etc. Interestingly however, neither MS Terminal nor VSCode exhibit this
limitation so the question was why. Enter custom `conpty.dll` and
`OpenConsole.exe` runtime. These are updated, developed in MS Terminal
tree subprojects that aim to replace native Windows API as well as
augment the `conhost.exe` process that runs by default in Windows. They
also fix all the woes we had with the terminal on Windows (there is a
chance that ctrl-c behaviour is also fixed with these, but still need to
double check that this is indeed the case). This PR ensures that Zed
also benefits from the update pseudoconsole API.
# Proposed approach
It is possible to fork MS Terminal and instrument the necessary
subprojects for Rust-awareness (using `cc-rs` or otherwise to compile
the C++ code and then embed it in Rust-produced binaries for easier
inclusion in projects) but it comes at a cost of added complexity,
maintenance burden, etc. An alternative approach was proposed by
@reflectronic to download the binary from the official Nuget repo and
bundle it for release/local use. This PR aims to do just that.
There are two bits to this PR:
1. ~~when building Zed locally, and more specifically, when the `zed`
crate is being built, we will strive to download and unpack the binaries
into `OUT_DIR` provided by `cargo`. We will then set
`ZED_CONPTY_INSTALL_PATH=${OUT_DIR}/conpty` and use it at runtime in Zed
binary to tweak the loader's search path with that additional path. This
effectively ensures that Zed built from source on Windows has full
terminal support.~~ EDIT: after several discussions offline, we've
decided that keeping it minimal will serve us best, meaning: when
developing locally it is up to the developer of Zed to install
`conpty.dll` and put it in the loader's search path.
2. when bundling Windows release, we will download and unpack the nuget
package into Zed's bundle which will ensure it is installed in the same
directory as Zed by the installer.
**Note** I realise that 1. may actually not be needed - instead we could
leave that bit for the user who wants to run Zed from source to ensure
that they have `conpty.dll` in the loader's search path. I'd love to
hear opinions on this!
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
- The fork with the patch is now included in 0.25.0
(7ff26dacd7).
- We no longer need `except*` as a keyword, which was added in
https://github.com/zed-industries/zed/pull/21389. It now highlights
correctly without explicitly mentioning it after
1b1ca93298.
Release Notes:
- N/A
Closes #ISSUE
Improves the efficiency of our interactions with the Zed language
server. Previously, on startup and after every workspace configuration
changed notification, we would send >1MB of JSON Schemas to the JSON
LSP. The only reason this had to happen was due to the case where an
extension was installed that would result in a change to the JSON schema
for settings (i.e. added language, theme, etc).
This PR changes the behavior to use the URI LSP extensions of
`vscode-json-language-server` in order to send the server URI's that it
can then use to fetch the schemas as needed (i.e. the settings schema is
only generated and sent when `settings.json` is opened. This brings the
JSON we send to on startup and after every workspace configuration
changed notification down to a couple of KB.
Additionally, using another LSP extension request we can notify the
server when a schema has changed using the URI as a key, so we no longer
have to send a workspace configuration changed notification, and the
schema contents will only be re-requested and regenerated if the schema
is in use.
Release Notes:
- Improved the efficiency of communication with the builtin JSON LSP.
JSON Schemas are no longer sent to the JSON language server in their
full form. If you wish to view a builtin JSON schema in the language
server info tab of the language server logs (`dev: open language server
logs`), you must now use the `editor: open url` action with your cursor
over the URL that is sent to the server.
- Made it so that Zed urls (`zed://...`) are resolved locally when
opened within the editor instead of being resolved through the OS. Users
who could not previously open `zed://*` URLs in the editor can now do so
by pasting the link into a buffer and using the `editor: open url`
action (please open an issue if this is the case for you!).
---------
Co-authored-by: Michael <michael@zed.dev>
std commands can block for an arbitrary duration and so runs risk of
blocking tasks for too long. This replaces all such uses where sensible
with async processes.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Uses the previously merged denoising crate (and fixes a bug in it that
snug in during refactoring) to add denoising to the microphone input.
Adds automatic volume control for microphone and output.
Prepares for migrating to 16kHz SR mono:
The experimental audio path now picks the samplerate and channel count depending on a setting. It can handle incoming streams with both the current (future legacy) and new samplerate & channel count. These are url-encoded into the livekit track name
Release Notes:
- N/A
- Map path lookup and internal failures to acp::Error
- Return INVALID_PARAMS for reads beyond EOF
Release Notes:
- acp: Return more informative error types from `read_text_file` to
agents
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
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>
Creates a new `EditPredictionProvider` for zeta2, that requests
completions from a new cloud endpoint including context from the new
`edit_prediction_context` crate. This is not ready for use, but it
allows us to iterate.
Release Notes:
- N/A
---------
Co-authored-by: Michael Sloan <michael@zed.dev>
Co-authored-by: Bennet <bennet@zed.dev>
Co-authored-by: Bennet Bo Fenner <bennetbo@gmx.de>
Expands on #38543 (notably allows setting importance categories and
weights on tests, and a lot of internal refactoring) because I couldn't
help myself. Also allows exporting runs to json and comparing across them. See code for docs.
Release Notes:
- N/A
Add an auto-profiler for our tests, to hopefully allow better triage of
performance impacts resulting from code changes. Comprehensive usage
docs are in the code.
Currently, it uses hyperfine under the hood and prints markdown to the
command line for all crates with relevant tests enabled. We may want to
expand this to allow outputting json in the future to allow e.g.
automatically comparing the difference between two runs on different
commits, and in general a lot of functionality could be added (maybe
measuring memory usage?).
It's enabled (mostly as an example) on two tests inside `gpui` and a
bunch of those inside `vim`. I'd have happily used `cargo bench`, but that's nightly-only.
Release Notes:
- N/A
When we refactored settings to not pass JSON blobs around, we ended up
needing
to write *a lot* of code that just merged things (like json merge used
to do).
Use a derive macro to prevent typos in this logic.
Release Notes:
- N/A
Adds a `dev: open edit prediction context` action that opens a new
workspace pane that displays the excerpts and snippets that would be
included in the edit prediction request.
Release Notes:
- N/A
---------
Co-authored-by: Bennet <bennet@zed.dev>
Co-Authored-By: Ben K <ben@zed.dev>
Co-Authored-By: Anthony <anthony@zed.dev>
Co-Authored-By: Mikayla <mikayla@zed.dev>
Release Notes:
- settings: Major internal changes to settings. The primary user-facing
effect is that some settings which did not make sense in project
settings files are no-longer read from there. (For example the inline
blame settings)
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Anthony <anthony@zed.dev>
The audio crate will use the denoise crate to remove background noises
from microphone input.
We intent to contribute this to rodio. Before that can happen a PR needs
to land in candle. Until then this lives here.
Uses a candle fork which removes the dependency on `protoc` and has the PR's mentioned above already applied.
Release Notes:
- N/A
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
The problem from issue #37509 comes from local virtual environments
created with certain approaches (including the 'simple' way of `python
-m venv`) not having a `.project` file with the path to the project's
root directory. When the toolchains are sorted, a virtual environment in
the project is not treated as being for that project and therefore is
not prioritized.
With this change, if a toolchain does not have a `project` associated
with it, we check to see if it is a virtual environment, and if it is we
use its parent directory as the `project`. This will make it the top
priority (i.e. the default) if there are no other virtual environments
for a project, which is what should be expected.
Closes#37509
Release Notes:
- Improved python toolchain prioritization of local virtual
environments.
serde 1.0.221 introduced serde_core into the build graph, which should
render explicitly depending on serde_derive for faster build times an
obsolote method.
Besides, I'm not even sure if that worked for us. My hunch is that at
least one of our deps would have `serde` with derive feature enabled..
and then, most of the crates using `serde_derive` explicitly were also
depending on gpui, which depended on `serde`.. thus, we wouldn't have
gained anything from explicit dep on `serde_derive`
Release Notes:
- N/A
@maxdeviant We can eventually turn down the panic telemetry endpoint,
but should probably leave it up while there's still a bunch of stable
users hitting it.
@maxbrunsfeld We're optimistic that this change also fixed the macos
crashed-thread misreporting. We think it was because the
`CrashContext::exception` was getting set to `None` only on macos, while
on linux it was getting a real exception value from the sigtrap. Now
we've unified and it uses `SIGABRT` on both platforms (I need to double
check that this works as expected for windows).
We unconditionally set `RUST_BACKTRACE=1` for the current process so
that we see backtraces when running in a terminal by default. This
should be fine but I just wanted to note it since it's a bit abnormal.
Release Notes:
- N/A
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Follow-up to #35250. Let's experiment with having this by default on
nightly.
Release Notes:
- Added built-in support for the basedpyright language server for Python
code. basedpyright is now enabled by default, and pyright (previously
the primary Python language server) remains available but is disabled by
default. This supersedes the basedpyright extension, which can be
uninstalled. Advantages of basedpyright over pyright include support for
inlay hints, semantic highlighting, auto-import code actions, and
stricter type checking. To switch back to pyright, add the following
configuration to settings.json:
```json
{
"languages": {
"Python": {
"language_servers": ["pyright", "pylsp", "!basedpyright"]
}
}
}
```
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
macOS versions are currently reported as `macOS 26.0.0`.
But this makes it impossible to differentiate amongst macOS Beta
releases which have the same version number (`X.0.0`) but are different
builds.
This PR adds build number info to `os_version` for macOS Betas and
[Rapid Security Response](https://support.apple.com/en-us/102657)
release that have identical version numbers to stable release, but have
different builds numbers. We can differentiate them because the build
numbers end with a letter.
| Version | Before | After |
| - | - | - |
| macOS Sonoma 14.7.8 | 14.7.8 | 14.7.8 |
| macOS Sequoia 15.6.1 | 15.6.1 | 15.6.1 |
| mcOS Ventura 13.3.1 | 13.3.1 | 13.3.1 |
| macOS Ventura 13.3.1 (a) | 13.3.1 | 13.3.1 (Build 22E772610a) |
| macOS Tahoe 26.0.0 (Beta1) | 26.0.0 | 26.0.0 (Build 25A5316a) |
| macOS Tahoe 26.0.0 (Beta5) | 26.0.0 | 26.0.0 (Build 25A5349a) |
This should cause minimal telemetry changes and only impacting a macOS
betas and a couple specific older macOS versions, but will allow
differentiation between macOS beta releases in GitHub issues.
Alternatives:
1. Leave as-is (can't differentiate between macOS beta builds)
2. Always include build number info (impacts telemetry; more consistent
going forward; differentiates non-final Release Candidates which don't
include a trailing letter)
I couldn't find a cocoa method to retrieve macOS build number, so I
switched dependencies from `cocoa` to `objc2-foundation` in the client
crate. We already depend upon this crate as a dependency of
`blade-graphics` so I matched the features of that and so workspace-hack
doesn't change.
1ebc69a447/tooling/workspace-hack/Cargo.toml (L355)
Release Notes:
- N/A
