- **WIP: reorganize dispositions**
- **Introduce a LocalToolchainStore trait and use it for LspAdapter
methods**
Closes#35782Closes#27331
Release Notes:
- Python: Improved propagation of a selected virtual environment into
the LSP configuration. This should the make all language-related
features such as Go to definition or Find all references more reliable.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Follow-up for #36093 and
https://github.com/zed-industries/zed/pull/36138
Since v1.355.0, `@github/copilot-language-server` has stopped responding
to `CheckStatus` requests if a `DidChangeConfiguration` notification
hasn’t been sent beforehand. This causes `CheckStatus` to remain in an
await state until it times out, leaving the connection stuck for a long
period before finally throwing a timeout error.
```rs
let status = server
.request::<request::CheckStatus>(request::CheckStatusParams {
local_checks_only: false,
})
.await
.into_response() // bails here with ConnectionResult::Timeout
.context("copilot: check status")?;
````
This PR fixes the issue by sending the `DidChangeConfiguration`
notification before making the `CheckStatus` request. It’s just an
ordering change i.e. no other LSP actions occur between these two calls.
Previously, we only updated our internal connection status and UI in
between.
Release Notes:
- Fixed an issue where GitHub Copilot could get stuck and fail to sign
in.
Closes#36093
Pin copilot version to 1.354 for now until further investigation.
Release Notes:
- Fixes issue where Copilot failed to sign in.
Co-authored-by: MrSubidubi <dev@bahn.sh>
This PR adds a built-in adapter for the basedpyright language server.
For now, it's behind the `basedpyright` feature flag, and needs to be
requested explicitly like this for staff:
```
"languages": {
"Python": {
"language_servers": ["basedpyright", "!pylsp", "!pyright"]
}
}
```
(After uninstalling the basedpyright extension.)
Release Notes:
- N/A
Temporarily fixes#29133
Co-authored-by: Cole <cole@zed.dev>
Release Notes:
- python: Zed now reports a slightly different set of workspace folders
for Python projects to work around quirks in handling of multi-lsp
projects with virtual environment. This behavior will be revisited in a
near future.
Co-authored-by: Cole <cole@zed.dev>
Closes#33238, follow-up to
https://github.com/zed-industries/zed/pull/29625.
Changes:
- Removed `significant_indentation`, which was the way to introduce
indentation scoping in languages like Python. However, it turned out to
be unnecessarily complicated to define and maintain.
- Introduced `decrease_indent_patterns`, which takes a `pattern` keyword
to automatically outdent and `valid_after` keywords to treat as valid
code points to snap to. The outdent happens to the most recent
`valid_after` keyword that also has less or equal indentation than the
currently typed keyword.
Fixes:
1. In Python, typing `except`, `finally`, `else`, and so on now
automatically indents intelligently based on the context in which it
appears. For instance:
```py
try:
if a == 1:
try:
b = 2
^ # <-- typing "except:" here would indent it to inner try block
```
but,
```py
try:
if a == 1:
try:
b = 2
^ # <-- typing "except:" here would indent it to outer try block
```
2. Fixes comments not maintaining indent.
Release Notes:
- Improved auto outdent for Python while typing keywords like `except`,
`else`, `finally`, etc.
- Fixed the issue where comments in Python would not maintain their
indentation.
Closes#33106
Instead of directly using `filter_text` in `StringMatchCandidate`, which
yields better results for fuzzy matching but messes up with highlighting
letters in bold, as `positions` list generated by fuzzy crate are now of
`filter_text` and not `label` shown to the user.
This PR fixes it by keeping use of `filter_range` in
`StringMatchCandidate`, which is range w.r.t to `label` shown to user.
And actually generating this `filter_range` at source by using
`filter_range` if exists.
- [x] Tests
Release Notes:
- Fixed issue where incorrect letters are marked as bold in completions.
Now, every JS/TS-related file will get their package.json script
contents added as tasks:
<img width="1020" alt="image"
src="https://github.com/user-attachments/assets/5bf80f80-fd72-4ba8-8ccf-418872895a25"
/>
To achieve that, `fn associated_tasks` from the `ContextProvider` was
made asynchronous and the related code adjusted.
Release Notes:
- Added initial `package.json` scripts task autodetection
---------
Co-authored-by: Piotr Osiewicz <piotr@zed.dev>
# Fix Python Virtual Environment Detection in Zed
## Problem
Zed was not properly detecting Python virtual environments when a
project didn't contain a `pyrightconfig.json` file. This caused Pyright
(the Python language server) to report `reportMissingImports` errors for
packages installed in virtual environments, even though the virtual
environment was correctly set up and worked fine in other editors.
The issue was that while Zed's `PythonToolchainProvider` correctly
detected virtual environments, this information wasn't being
communicated to Pyright in a format it could understand.
## Root Cause
The main issue was in how Zed communicated virtual environment
configuration to Pyright through the Language Server Protocol (LSP).
When Pyright requests workspace configuration, it expects virtual
environment settings (`venvPath` and `venv`) at the root level of the
configuration object - the same format used in `pyrightconfig.json`
files. However, Zed was attempting to place these settings in various
nested locations that Pyright wasn't checking.
## Solution
The fix involves several coordinated changes to ensure Pyright receives
virtual environment configuration in all the ways it might expect:
### 1. Enhanced Workspace Configuration (`workspace_configuration`
method)
- When a virtual environment is detected, Zed now sets `venvPath` and
`venv` at the root level of the configuration object, matching the exact
format of a `pyrightconfig.json` file
- Uses relative path `"."` when the virtual environment is located in
the workspace root
- Also sets `python.pythonPath` and `python.defaultInterpreterPath` for
compatibility with different Pyright versions
### 2. Environment Variables for All Language Server Binaries
- Updated `check_if_user_installed`, `fetch_server_binary`,
`check_if_version_installed`, and `cached_server_binary` methods to
include shell environment variables
- This ensures environment variables like `VIRTUAL_ENV` are available to
Pyright, helping with automatic virtual environment detection
### 3. Initialization Options
- Added minimal initialization options to enable Pyright's automatic
path searching and import completion features
- Sets `autoSearchPaths: true` and `useLibraryCodeForTypes: true` to
improve Pyright's ability to find packages
## Key Changes
The workspace configuration now properly formats virtual environment
configuration:
- Root level: `venvPath` and `venv` (matches pyrightconfig.json format)
- Python section: `pythonPath` and `defaultInterpreterPath` for
interpreter paths
## Impact
- Users no longer need to create a `pyrightconfig.json` file for virtual
environment detection
- Python projects with virtual environments in standard locations
(`.venv`, `venv`, etc.) will work out of the box
- Import resolution for packages installed in virtual environments now
works correctly
- Maintains compatibility with manual `pyrightconfig.json` configuration
for complex setups
## Testing
The changes were tested with Python projects using virtual environments
without `pyrightconfig.json` files. Pyright now correctly resolves
imports from packages installed in the virtual environment, eliminating
the `reportMissingImports` errors.
## Release Notes
- Fixed Python virtual environment detection when no
`pyrightconfig.json` is present
- Pyright now correctly resolves imports from packages installed in
virtual environments (`.venv`, `venv`, etc.)
- Python projects with virtual environments no longer show false
`reportMissingImports` errors
- Improved Python development experience with automatic virtual
environment configuration
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
This reverts commit 1e55e88c18.
Closes #ISSUE
Release Notes:
- Python toolchain selector now uses path to the closest pyproject.toml
as a basis for picking a toolchain. All files under the same
pyproject.toml (in filesystem hierarchy) will share a single virtual
environment. It is possible to have multiple Python virtual environments
selected for disjoint parts of the same project.
# Fix Python venv Detection for Test Runner
## Problem
Zed’s Python test runner was not reliably detecting and activating the
project’s Python virtual environment (.venv or venv), causing it to
default to the system Python. This led to issues such as missing
dependencies (e.g., pytest) when running tests.
## Solution
Project Root Awareness: The Python context provider now receives the
project root path, ensuring venv detection always starts from the
project root rather than the test file’s directory.
Robust venv Activation: The test runner now correctly detects and
activates the Python interpreter from .venv or venv in the project root,
setting VIRTUAL_ENV and updating PATH as needed.
Minimal Impact: The change is limited in scope, affecting only the
necessary code paths for Python test runner venv detection. No broad
architectural changes were made.
## Additional Improvements
Updated trait and function signatures to thread the project root path
where needed.
Cleaned up linter warnings and unused code.
## Result
Python tests now reliably run using the project’s virtual environment,
matching the behavior of other IDEs and ensuring all dependencies are
available.
Release Notes:
- Fixed Python tasks always running with a toolchain selected for the
root of a workspace.
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Parses project's package.json to better detect Jasmine, Jest, Vitest and
Mocha and `test`, `build` scripts presence.
Also tries to detect `pnpm` and `npx` as test runners, falls back to
`npm`.
https://github.com/user-attachments/assets/112d3d8b-8daa-4ba5-8cb5-2f483036bd98
Release Notes:
- Improved TypeScript task detection
That commit broke a lot, as our one-off tasks (alt-enter in the tasks
modal), npm, jest tasks are all not real commands, but a composition of
commands and arguments.
This reverts commit 5db14d315b.
Closes https://github.com/zed-industries/zed/issues/31554
Release Notes:
- N/A
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Closes #ISSUE
Release Notes:
- debugger: Python tests/main functions can now we debugged from the
gutter.
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
This commit effectively re-implements #21981 in task system. commands
with spaces cannot be spawned currently, and we don't want to have to
deal with shell variables wrapped in "" in DAP locators.
Closes #ISSUE
Release Notes:
- Fixed an issue where tasks with spaces in `command` field could not be
spawned.
Follow-up to #29625 and #30902
This PR reintroduces auto-intents for brackets in Python and fixes some
cases where an indentation would be triggered if it should not. For
example, upon typing
```python
a = []
```
and inserting a newline after, the next line would be indented although
it shoud not be.
Bracket auto-indentation was tested prior to #29625 but removed there
and the test updated accordingly. #30902 reintroduced this for all
brackets but `()`. I reintroduced this here, reverted the changes to the
test so that indents also happen after typing `()`. This is frequently
used for tuples and multiline statements in Python.
Release Notes:
- Improved auto-indentation when using round brackets in Python.
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#26157
This fixes multiple cases where Python indentation breaks:
- [x] Adding a new line after `if`, `try`, etc. correctly indents in
that scope
- [x] Multi-cursor tabs correctly preserve relative indents
- [x] Adding a new line after `else`, `finally`, etc. correctly outdents
them
- [x] Existing Tests
Future Todo: I need to add new tests for all the above cases.
Before/After:
1. Multi-cursor tabs correctly preserve relative indents
https://github.com/user-attachments/assets/08a46ddf-5371-4e26-ae7d-f8aa0b31c4a2
2. Adding a new line after `if`, `try`, etc. correctly indents in that
scope
https://github.com/user-attachments/assets/9affae97-1a50-43c9-9e9f-c1ea3a747813
Release Notes:
- Fixes indentation-related issues involving tab, newline, etc for
Python.
- Languages now define their preferred debuggers in `config.toml`.
- `LanguageRegistry` now exposes language config even for languages that
are not yet loaded. This necessitated extension registry changes (we now
deserialize config.toml of all language entries when loading new
extension index), but it should be backwards compatible with the old
format. /cc @maxdeviant
Release Notes:
- N/A
---------
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Remco Smits <djsmits12@gmail.com>
Co-authored-by: Anthony <anthony@zed.dev>
This reverts commit e661a0afd6.
Closes #ISSUE
Release Notes:
- Reverted changes to Python subroot detection which could have caused
multiple python processes to be spawned when working in projects with
multiple `pyproject.toml` files.
Python envs created with virtualenvwrapper have the ability to link to
the project directory (via the `.project` file in the virtualenv).
`python-environment-tools` supports this and reports the project path.
Additionally, some tools (e.g virtualfish) recognize special
"environment activation" files in project directories (`.venv` by
default)
[1].
Use the above information to sort reported Python toolchains so that the
correct env for a given worktree is at the top.
[1]
https://virtualfish.readthedocs.io/en/latest/plugins.html#auto-activation-auto-activation
Release Notes:
- python: Improved detection of virtualenvwrapper environments in work
trees
Right now the toolchain popup is a nondescript list of duplicate entries
like `Python 3.10.15 (VirtualEnvWrapper)` and one has to look at the
interpreter path to distinguish one virtualenv from another.
Fix this by including the env name as reported by pet, so the entries
looks like `Python 3.10.15 (myproject; VirtualEnvWrapper)`.
Release Notes:
- Python: Improved display of environments in toolchain selector
Closes#26460
I am new to contributing to Zed (and pretty new to Rust in general). I'm
not too familiar with code style, guidelines etc. so please feel free to
suggest changes/improvements.
This PR adds a run icon to Python files that have a "main" function:
```python
if __name__ == "__main__":
...
```
In addition to the gutter icon, there is now also an extra task in the
command palette "run module".
Release Notes:
- Added detection for runnable Python modules
- Added Python-specific task to run a Python file as a module from
inside the project's scope
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Makes Python plugin to output
for standalone Python files now, instead of nothing as now.
Before the change, no task context was created for the standalone file
due to `VariableName::RelativeFile` lookup considered as an error.
Now, Zed continues and constructs whatever possible context instead.
That `pytest` task seems odd, as the logic fixed here needs a relative
path (hence, a worktree) to consider unit tests.
We do not have variables at the moment the associated tasks are queried
for:
14920ab910/crates/languages/src/python.rs (L359-L363)14920ab910/crates/languages/src/python.rs (L417-L446)
so we cannot filter this the same way the PR does.
Maybe, we can use a `VariableName::RelativeFile` instead of
`VariableName::File` there?
Release Notes:
- Show tasks from Python plugin for standalone files
This is the core change:
https://github.com/zed-industries/zed/pull/26758/files#diff-044302c0d57147af17e68a0009fee3e8dcdfb4f32c27a915e70cfa80e987f765R1052
TODO:
- [x] Use AsyncFn instead of Fn() -> Future in GPUI spawn methods
- [x] Implement it in the whole app
- [x] Implement it in the debugger
- [x] Glance at the RPC crate, and see if those box future methods can
be switched over. Answer: It can't directly, as you can't make an
AsyncFn* into a trait object. There's ways around that, but they're all
more complex than just keeping the code as is.
- [ ] Fix platform specific code
Release Notes:
- N/A
Closes#24565
As pointed out in
https://github.com/zed-industries/zed/issues/24565#issuecomment-2657822723
, the name for the Pyright language server is `pyright-langserver`, not
`pyright`. The latter is a CLI-tool as described in
https://microsoft.github.io/pyright/#/command-line which only provides
static type checking. It has neither LSP-capabilities nor a `--stdio`
argument. Thus, the error as shown in the linked issue appears.
I disagree with the fix as described in
https://github.com/zed-industries/zed/issues/24565#issuecomment-2657904208
, as it could only cause this error to reappear in rare scenarios where
Pyright, but not the Pyright language server is installed in a user's
environment. Just checking for `pyright-langserver` to be present in the
environment seems more straightforward here.
Release Notes:
- Python: Fixed Pyright failing to start when installed locally
Co-authored-by: Beniamin Zagan <47153906+beniaminzagan@users.noreply.github.com>
Fix a bug where a GPUI macro still used `ModelContext`
Rename `AsyncAppContext` -> `AsyncApp`
Rename update_model, read_model, insert_model, and reserve_model to
update_entity, read_entity, insert_entity, and reserve_entity
Release Notes:
- N/A
There's still a bit more work to do on this, but this PR is compiling
(with warnings) after eliminating the key types. When the tasks below
are complete, this will be the new narrative for GPUI:
- `Entity<T>` - This replaces `View<T>`/`Model<T>`. It represents a unit
of state, and if `T` implements `Render`, then `Entity<T>` implements
`Element`.
- `&mut App` This replaces `AppContext` and represents the app.
- `&mut Context<T>` This replaces `ModelContext` and derefs to `App`. It
is provided by the framework when updating an entity.
- `&mut Window` Broken out of `&mut WindowContext` which no longer
exists. Every method that once took `&mut WindowContext` now takes `&mut
Window, &mut App` and every method that took `&mut ViewContext<T>` now
takes `&mut Window, &mut Context<T>`
Not pictured here are the two other failed attempts. It's been quite a
month!
Tasks:
- [x] Remove `View`, `ViewContext`, `WindowContext` and thread through
`Window`
- [x] [@cole-miller @mikayla-maki] Redraw window when entities change
- [x] [@cole-miller @mikayla-maki] Get examples and Zed running
- [x] [@cole-miller @mikayla-maki] Fix Zed rendering
- [x] [@mikayla-maki] Fix todo! macros and comments
- [x] Fix a bug where the editor would not be redrawn because of view
caching
- [x] remove publicness window.notify() and replace with
`AppContext::notify`
- [x] remove `observe_new_window_models`, replace with
`observe_new_models` with an optional window
- [x] Fix a bug where the project panel would not be redrawn because of
the wrong refresh() call being used
- [x] Fix the tests
- [x] Fix warnings by eliminating `Window` params or using `_`
- [x] Fix conflicts
- [x] Simplify generic code where possible
- [x] Rename types
- [ ] Update docs
### issues post merge
- [x] Issues switching between normal and insert mode
- [x] Assistant re-rendering failure
- [x] Vim test failures
- [x] Mac build issue
Release Notes:
- N/A
---------
Co-authored-by: Antonio Scandurra <me@as-cii.com>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Mikayla <mikayla@zed.dev>
Co-authored-by: Joseph <joseph@zed.dev>
Co-authored-by: max <max@zed.dev>
Co-authored-by: Michael Sloan <michael@zed.dev>
Co-authored-by: Mikayla Maki <mikaylamaki@Mikaylas-MacBook-Pro.local>
Co-authored-by: Mikayla <mikayla.c.maki@gmail.com>
Co-authored-by: joão <joao@zed.dev>
Part of https://github.com/zed-industries/zed/issues/22606
Before, `tsdk_path` for vtsls and typescript-language-server
unconditionally set a `tsdk`/`tsserver` property for the corresponding
language server, even if there were no such directory at all.
Instead, make the corresponding code to omit such property if it was not
found on the FS.
Release Notes:
- Fixed "The path /.../tsserver.js doesn't point to a valid tsserver
install. Falling back to bundled TypeScript version." pop-up appearing
Goal: Allow zed to locate [`pixi`](https://github.com/prefix-dev/pixi)
environments
Changes:
- Uses a newer release of
[`python-environment-tools`](https://github.com/microsoft/python-environment-tools)
with the new `pet-pixi` create
- Adds `PythonEnvironmentKind::Pixi` as a possible environment kind, to
allow the rest of the code to detect the environment
I tested the changes locally. It found the correct pixi environment and
I was able to run `pytest` through the UI icon.
Release Notes:
- Added detection for pixi-environments
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Closes #ISSUE
- #21452
Describe the bug / provide steps to reproduce it
Language server error: pylsp
failed to spawn command. path:
"C:\Users\AppData\Local\Zed\languages\pylsp\pylsp-venv\bin\pylsp",
working directory: "D:\Coding\Python", args: []
-- stderr--
Environment
- Windows 11
- python
Release Notes:
- Windows: Fixed the path building used to run `pip` commands in the
venv generated on Windows 11.
---------
Co-authored-by: Marshall Bowers <elliott.codes@gmail.com>
This message has confused me many times too: we printed the status as
"Downloading" when we were only checking whether we need to install a
given version of a language server.
This fixes the issue for Node-based language servers where we had the
same check in all implementations.
Closes #22241
Release Notes:
- Fixed some language servers reporting status as "Downloading..." when
only a version check was being done.
This PR fixes running Python commands that include paths with spaces by
wrapping python commands and their arguments in quotation marks.
I fixed this only in Python as I noticed this while trying to run
`pytest` in Zed.
Probably this is not the best approach as it doesn't fix other languages
too, though I don't know enough about the codebase to fix it like that.
I'm not even sure if it's actually feasible right now.
I didn't add tests for this either as I couldn't really understand how
to easily to that, I tried to look at other languages but couldn't find
one that tests their `ContextProvider` directly.
Release Notes:
- Fix running Python commands that include paths with spaces
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
