Implements a specialized constructor `LanguageName::new_static` for
`&'static str` which reduces allocations.
`LanguageName::new` always backs the underlying `SharedString` with an
owned `Arc<str>` even when a `&'static str` is passed. This makes us
allocate each time we create a new `LanguageName` no matter what.
Creating a specialized constructor for `&'static str` allows us to
essentially construct them for free.
Additional change:
Encourages using explicit constructors to avoid needless allocations.
Currently there were no instances of this trait being called where the
lifetime was not `'static` saving another 48 locations of allocation.
```rust
impl<'a> From<&'a str> for LanguageName {
fn from(str: &'a str) -> Self {
Self(SharedString::new(str))
}
}
// to
impl From<&'static str> for LanguageName {
fn from(str: &'static str) -> Self {
Self(SharedString::new_static(str))
}
}
```
Release Notes:
- N/A
Closes#44090
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Release Notes:
- python: Improved sorting order of toolchains in monorepos with
multiple local virtual environments.
- python: Fixed toolchain selector not having an active toolchain
selected on open.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Smit <smit@zed.dev>
Gist is we only need to block the foreground thread for reparsing if
immediate language changes are useful to the user. That is usually only
the case when they edit the buffer
Release Notes:
- Improved performance of large project searches and project diffs
Co-authored by: David Kleingeld <david@zed.dev>
Closes#9648#9755
Release Notes:
- Added way to configure ESLint's working directories in settings. For
example:
`{"lsp":{"eslint":{"settings":{"workingDirectories":["./client","./server"]}}}}`
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Verified that this works locally. I modeled it after how basedpyright
and pyright work. Here is a screenshot of what it looks like (issue has
screenshots of the old state):
<img width="593" height="258" alt="Screenshot 2025-11-07 at 2 40 50 PM"
src="https://github.com/user-attachments/assets/5d2371fc-360b-422f-ba59-0a95f2083c87"
/>
Closes#42232
Release Notes:
- python/ty: Code completion menu now shows packages that will be
imported when a given entry is accepted.
Closes#40576
This PR makes Conda activation configurable and transparent by adding a
`terminal.detect_venv.on.conda_manager` setting (`"auto" | "conda" |
"mamba" | "micromamba"`, default `"auto"`), updating Python environment
activation to honor this preference (or the detected manager executable)
and fall back to `conda` when necessary.
The preference is passed via `ZED_CONDA_MANAGER` from the terminal
settings, and the activation command is built accordingly (with proper
quoting for paths). Changes span
`zed/crates/terminal/src/terminal_settings.rs` (new `CondaManager` and
setting), `zed/crates/project/src/terminals.rs` (inject env var),
`zed/crates/languages/src/python.rs` (activation logic), and
`zed/assets/settings/default.json` (document the setting). Default
behavior remains unchanged for most users while enabling explicit
selection of `mamba` or `micromamba`.
Release Notes:
- Added: terminal.detect_venv.on.conda_manager setting to choose the
Conda manager (auto, conda, mamba, micromamba). Default: auto.
- Changed: Python Conda environment activation now respects the
configured manager, otherwise uses the detected environment manager
executable, and falls back to conda.
- Reliability: Activation commands quote manager paths to handle spaces
across platforms.
- Compatibility: No breaking changes; non-Conda environments are
unaffected; remote terminals are supported.
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
If you set `{"basedpyright": {"analysis": {"typeCheckingMode":
"off"}}}`, you will notice that it doesn't actually work, but
`{"basedpyright.analysis": {"typeCheckingMode": "off"}}` does.
Made the change on how the default is being set.
Release Notes:
- N/A
This means that existence of activation scripts for venv/virtualenv will
be checked locally either on the host if editing locally, or the remote
by the remote proxy if editing a remote project.
Closes https://github.com/zed-industries/zed/issues/40263
Release Notes:
- N/A
Fixes#39998
Debugpy and pylsp are installed in a Zed-global venv with pip. We need a
Python interpreter to create this venv when it doesn't exist and one of
these tools needs to be installed, and sometimes we attempt to use
`python3` from `$PATH`. This can cause issues on Windows, where out of
the box `python3` is a sort of shim that opens the Microsoft Store app.
This PR changes the debugpy installation path to create the Zed-global
venv using the Python interpreter from a venv in the project, and only
use python3 from `$PATH` if that fails. That matches how pylsp
installation already works. It also tightens up how we search for a
global Python installation by doing a basic sanity check (`python3 -c
'print(1 + 2)`) before accepting it, which should catch the Windows
shim.
Release Notes:
- windows: improved the behavior of Zed in situations where no global
Python installation exists.
A couple of caveats:
- We should not auto-escape arguments with Alacritty's `escape_args`
option if using CMD otherwise, the generated command will have way too
many escaped characters for CMD to parse correctly.
- When composing a full command for CMD, we need to put it in double
quotes manually: `cmd /C "activate.bat& pwsh.exe -C do_something"` so
that CMD executes the entire string as a sequence of commands.
- CMD requires `&` as a chaining operator for commands (`;` for other
shells).
Release Notes:
- N/A
Now we use GitHub Releases to detect when there's a new version of
codex-acp out, and we notify the user in the same way we do for the
other external agents.
This also moves `github_download.rs` out of the `languages` crate and
into `http_client`, because now we're not just using it for language
servers anymore, we're also using it for external agents.
Release Notes:
- N/A
---------
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
When sourcing the project environment for the terminal tool, we will now
do so by spawning the shell specified by the users `terminal.shell`
setting (or as usual fall back to the login shell).
Closes#37687
Release Notes:
- N/A
This is a follow up to #37510 and is also related to #38910.
Release Notes:
- Improved ordering of virtual environments, sort by distance to
worktree root.
Closes#38553
Release Notes:
- Fixed wrong AssetKind specified on linux for ty
As discussed in the linked issue. All of the non windows assets for ty
are `tar.gz` files. This change applies that fix.
Closes https://github.com/zed-industries/zed/issues/38690Closes#37353
### Background
On Windows, paths are normally separated by `\`, unlike mac and linux
where they are separated by `/`. When editing code in a project that
uses a different path style than your local system (e.g. remoting from
Windows to Linux, using WSL, and collaboration between windows and unix
users), the correct separator for a path may differ from the "native"
separator.
Previously, to work around this, Zed converted paths' separators in
numerous places. This was applied to both absolute and relative paths,
leading to incorrect conversions in some cases.
### Solution
Many code paths in Zed use paths that are *relative* to either a
worktree root or a git repository. This PR introduces a dedicated type
for these paths called `RelPath`, which stores the path in the same way
regardless of host platform, and offers `Path`-like manipulation APIs.
RelPath supports *displaying* the path using either separator, so that
we can display paths in a style that is determined at runtime based on
the current project.
The representation of absolute paths is left untouched, for now.
Absolute paths are different from relative paths because (except in
contexts where we know that the path refers to the local filesystem)
they should generally be treated as opaque strings. Currently we use a
mix of types for these paths (std::path::Path, String, SanitizedPath).
Release Notes:
- N/A
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Peter Tripp <petertripp@gmail.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
Closes#38347
Release Notes:
- Fixed path and args to ty lsp binary
When attempting to use the new ty lsp integration in the preview, I
noticed issues related to accessing the binary. After deleting the
downloaded archive and adding the following changes that:
- downloads the archive with the correct `AssetKind::TarGz`
- uses the correct path to the extracted binary
- adds the `server` argument to initialize the lsp (like ruff)
After the above changes the LSP starts correctly
```bash
2025-09-18T16:17:03-05:00 INFO [lsp] starting language server process. binary path: "/Users/dereknguyen/Library/Application Support/Zed/languages/ty/ty-0.0.1-alpha.20/ty-aarch64-apple-darwin/ty", working directory: "/Users/dereknguyen/projects/test-project", args: ["server"]
```
<img width="206" height="98" alt="image"
src="https://github.com/user-attachments/assets/8fcf423f-40a0-4cd9-a79e-e09666323fe2"
/>
---------
Co-authored-by: Cole Miller <cole@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 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.
Part of reworking our installation handling to allow for multiple
different versions to be handled
Release Notes:
- Fixed pre-release lsp fetching setting not having an affect until
restarting Zed
Release Notes:
- python: The Ruff native language server is now available without
installing an extension.
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Closes#36491
This issue is caused by the Python language configuration treating
compound statements (such as for loops and if statements) that end with
an inline comment as not requiring an increased indent.
Release Notes:
- python: Correctly indent lines starting the blocks (for, finally, if,
else, try) that have trailing comments.
Pyright sets different `sortText` based on whether a given completion
item was recently resolved. This probably lines up with VSCode's way of
resolving items, but it's a no-no for us, as it makes completions
unstable.
Closes#9983
Release Notes:
- python: Fixed code completions having arbitrary order when using
Pyright/basedpyright
