Closed#33759Closed#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.
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>
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
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.
Closes#37028
I noticed many projects use Tailwind in plain TypeScript (.ts) files, so
it makes sense to support them out of the box, alongside .js and .tsx
files we already handle. For example, see
[supabase](https://github.com/supabase/supabase/blob/master/packages/ui/src/lib/theme/defaultTheme.ts).
Note: You’ll still need to add `"classFunctions": ["cva", "cx"],`
manually for Tailwind completions to work in `cva` type methods. This is
because you don’t want completions on every string, only in specific
methods or regex matches. This is documented.
Release Notes:
- Added out-of-the-box support for Tailwind completions in `.ts` files.
support for injecting sql, json, yaml, xml, html, css, js, lua and csv
value
if you use `/* lang */` before string literals, highlights them
**Example:**
```go
const sqlQuery = /* sql */ "SELECT * FROM users;" // highlights as SQL code
```
<img width="629" height="46" alt="Screenshot 2025-09-05 at 06 17 49"
src="https://github.com/user-attachments/assets/80f404d8-0a47-428d-bdb5-09fbee502cfe"
/>
Closes #ISSUE
Release Notes:
- Go: Added support for injecting sql, json, yaml, xml, html, css, js, lua and csv language highlights into string literals, when they are prefixed with `/* lang */`
**Example:**
```go
const sqlQuery = /* sql */ "SELECT * FROM users;" // Will be highlighted as SQL code
```
Now logs warnings for unrecognized capture names and logs errors for
missing required captures.
Release Notes:
- N/A
---------
Co-authored-by: Max <max@zed.dev>
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
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>
Required for https://github.com/isographlabs/isograph/pull/568 to work
properly. Tested with a local build and made sure everything's working
great!
Release Notes:
- JavaScript/TypeScript/JSX: Added support for injecting Isograph language support into `iso`
function calls
- **toolchains: Add new state to toolchain selector**
- **Use toolchain term for Add Toolchain button**
- **Hoist out a meta function for toolchain listers**
Closes#27332
Release Notes:
- python: Users can now specify a custom path to their virtual
environment from within the picker.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This isn't quite right, but using the env manager path causes conda to
scream and I am not yet sure why, either way this is an improvement over
the status quo
Release Notes:
- N/A\
Hi! As part of https://github.com/zed-extensions/ruby/issues/162 we
would like to rename HTML/ERB to HTML+ERB since it is more syntactically
correct to treat such language as ERB on top of HTML rather than HTML or
ERB.
To keep the user experience intact, we outlined the prerequisites in the
linked issue. This is the first PR that adds the HTML+ERB language name
to the list of enabled languages for the Emmet extension. We will do the
same for the Tailwind configuration in the Zed codebase. Once the new
versions of Emmet and Zed are released, we will merge the pull request
in the Ruby extension repository and release the updated version. After
that, we will remove the old HTML/ERB and YAML/ERB languages. Let me
know if that sounds good. Thanks!
Release Notes:
- N/A
Co-authored-by: Marshall Bowers <git@maxdeviant.com>
Closes#36420
## Synopsis
The issue in #36420 is caused by #7276, which bound the appropriate
tree-sitter queries to the `@variable.member` color. However, I have
found neither this color's declaration nor its other usages in the
codebase (neither on the latest `main` nor on
79c1003b34).
Other languages use for such situations the `@property` color.
## Solution
Just change the used `@variable.member` color to the `@property` one.
Seems fully inline with the changes illustrated in #7276.
## Screenshots
<img width="856" height="465" alt="Screenshot 2025-08-28 at 13 18 38"
src="https://github.com/user-attachments/assets/9d1f3542-8749-421f-864f-959c1242cc64"
/>
<img width="837" height="462" alt="Screenshot 2025-08-28 at 13 20 08"
src="https://github.com/user-attachments/assets/36a80c22-9de9-46b1-87e3-7fdeaa62978f"
/>
## Changelog
Release Notes:
- go: Fixed highlighting of fields.
Instead of manually constructing the venv we now ask the python
toolchain for the relevant information, unifying the approach of vent
inspection
Fixes https://github.com/zed-industries/zed/issues/27350
Release Notes:
- Improved the detection of python virtual environments for terminals
and tasks in remote projects.
This makes sure we do not apply the highlights for snake case
identifiers as well as paths for attributes too broadly to all types of
macros, which should make macros much more readable overall whilst
keeping the highlighting for the attribute items.
| Before | After |
| --- | --- |
| <img width="1414" height="958" alt="Bildschirmfoto 2025-08-28 um 00 37
58"
src="https://github.com/user-attachments/assets/1254b9a2-d07a-4be4-9b4f-555a7c640302"
/> | <img width="1414" height="958" alt="Bildschirmfoto 2025-08-28 um 00
37 38"
src="https://github.com/user-attachments/assets/5f6dd66c-5469-4f27-9f1d-0a6e6e8d8085"
/> |
Release Notes:
- rust: Improved highlighting within macros.
This PR adds the ability for a user to select one or more blocks of text
and wrap each selection in an HTML tag — which works by placing multiple
cursors inside the open and close tags so the appropriate element name
can be typed in to all places simultaneously.
This is similar to the emmet "Wrap with Abbreviation" functionality
discussed in #15588 but is a simpler version that does not rely on
Emmet's language server.
Here's a preview of the feature in action:
https://github.com/user-attachments/assets/1931e717-136c-4766-a585-e4ba939d9adf
Some notes and questions:
- The current implementation is a hardcoded with regards to supported
languages. I'd love some direction on how much of this information to
push into the relevant language structs.
- I can see this feature as something that languages added by an
extension would want to enable support for — is this something you'd
want?
- The syntax is hardcoded to support HTML/XML/JSX-like languages. I
don't suppose this is a problem but figured I'd point it out anyway.
- I called it "Wrap in tag" but open to whatever naming you feel is
appropriate.
- The implementation doesn't use `manipulate_lines` — I wasn't sure how
make use of that without extra overhead / bookkeeping — does this seem
fine?
- I could also investigate adding wrap in abbreviation support by
communicating with the Emmet language server but I think I'll need some
direction on how to handle Emmet's custom LSP message. I could do this
either in addition to or instead of this feature — though imo this
feature is a nice "shortcut" regardless.
Release Notes:
- Added a new "Wrap Selections in Tag" action that lets you wrap one or
more selections in tags based on language. Works in HTML, JSX, and
similar languages, and places cursors inside both opening and closing
tags so you can type the tag name once and apply it everywhere.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
cc @michael-ud - if you can build Zed, I'd appreciate it if you could
give this a go with your project. Otherwise I can provide a link to
download of current nightly via an e-mail for you to try out (if you
want).
This change will land in Preview (if merged) on next Wednesday and then
it'll be in Stable a week after that.
Related to: #20402
Release Notes:
- python: Zed now searches for virtual environments in intermediate
directories between a root of the worktree and the location of
pyproject.toml applicable to the currently focused file.
Kaikai