## Summary
Extends #51311 to JSX in JavaScript files, which uses the same
javascript grammar for both .js and .jsx.
## Changes
- Added (#set! rainbow.exclude) to the three angle bracket patterns in
crates/grammars/src/javascript/brackets.scm, matching the TSX fix in
#51311.
## Before / After
Before: angle brackets in JSX tags receive rainbow colors alongside
`{}`, `()`, `[]`, making every tag visually noisy.
After: only `{}`, `()`, and `[]` receive rainbow colors — angle brackets
are excluded, matching the HTML extension behavior.
Release Notes:
- Fixed angled brackets being included in rainbow bracket highlights for
JavaScript.
## Context
<!-- What does this PR do, and why? How is it expected to impact users?
Not just what changed, but what motivated it and why this approach.
Link to Linear issue (e.g., ENG-123) or GitHub issue (e.g., Closes#456)
if one exists — helps with traceability. -->
Closes https://github.com/zed-industries/zed/issues/52242
This PR reverts a change that highlights shell script arguments as
variables rather than strings. Because of how shell scripts work, all
parameters are strings by default and are regularly represented as such.
The original PR (https://github.com/zed-industries/zed/pull/48067) aimed
to improve highlighting by capturing all arguments as
`variable.parameter`s, but this doesn't align with the idiomatic usage
of shell scripts.
| Current Behavior | Expected Behavior |
|---|---|
| <img width="242" height="84" alt="Image"
src="https://github.com/user-attachments/assets/50c87198-e4be-4627-a742-88060b2b9d14"
/> | <img width="227" height="83" alt="Image"
src="https://github.com/user-attachments/assets/f08b1c62-9c7a-460e-b306-4ac6b9e5a897"
/> |
| Text arguments are highlighted as variable | Text arguments are
highlighted as "string" |
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- N/A or Added/Fixed/Improved ...
Resolves https://github.com/zed-industries/zed/issues/56478
This diff fixes Bash syntax highlighting for conditional and arithmetic
expressions. The Bash parser already recognizes tokens like `[[`, `]]`,
`((`, `))`, `$((`, `!=`, and `||`, but Zed’s Bash highlight query was
not capturing several of them.
With this change, the Bash highlight query styles those operators and
delimiters consistently with existing shell operators, brackets, and
special punctuation.
| Before | After |
| --- | --- |
| <img width="1667" height="1088" alt="ayu-old"
src="https://github.com/user-attachments/assets/0a89bd71-0a13-4ebe-8bc9-abc27ab42ed8"
/> | <img width="1667" height="1088" alt="ayu-new"
src="https://github.com/user-attachments/assets/afa5e8ab-f94a-4f5e-8fe8-770bac07559a"
/> |
Release Notes:
- Fixed bash syntax highlighting for conditional expressions, arithmetic
expressions, and related operators.
The highlight queries only matched JSX member-expression tags when the
object was a plain identifier (`<A.B>`), so tags with more than one dot
like `<A.B.C>` lost their component-tag highlighting.
The fix explicitly captures every leaf `identifier` and
`property_identifier` at each nesting depth (up to 3 levels) in the
JavaScript and TSX highlight queries so each token gets its own
`@tag.component.jsx` capture that beats the generic `@property` rule.
A more concise approach, capturing the whole nested
`(member_expression)` node as a single `@tag.component.jsx` blob, does
not work because the generic `(property_identifier) @property` rule
targets a smaller, more specific node inside the blob, winning the
resolution for inner segments like `B` in `<A.B.C>`.
Closes#53305
Release Notes:
- Fixed highlighting for nested JSX member expression tags in JavaScript
and TSX files.
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
No, sadly, the title is not a typo. See
https://www.githubstatus.com/incidents/zsg1lk7w13cf for the context.
I'll read with joy and popcorn through that root cause analysis.
It makes literally zero sense what happened here, but for some completly
bonkers reason GitHub completely messed up the merge queue with
https://github.com/zed-industries/zed/pull/54632.
I have no idea how it happened. It makes literally zero sense. A PR
going into the merge queue should have the same LoC when getting out of
it. GitHub obviously does not check this. GitHub causes extra work with
a feature that is supposed to save time.
Thanks, I guess.
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
This PR brings back the button to filter remote branches when accessing
the title bar's branch picker with the mouse. It was unintentionally
removed when we introduced the new worktree picker.
Release Notes:
- N/A
Uses tree-sitter indent queries to create a pseudo-scope, since access
modifiers are single-node in thetree-sitter grammar.
The @outdent capture truncates the parent { } indent range at the access
specifier, keeping it at the same level as the class keyword and the
pseudo-scopes from stacking.
The @outdent range selects siblings so we don't outdent the access
specifiers themselves, since screenshots from the reference issue seem
to show that at least one interested party does not prefer outdented
access modifiers, and also it seemed like less of a departure from
existing design.
Also, there are probably more tests than needed because this is my first
time writing treesitter queries and I wanted to triple-guess myself.
Quite open too feedback on which ones are more valuable.
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [x] Unsafe blocks (if any) have justifying comments
- [x] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [x] Tests cover the new/changed behavior
- [x] Performance impact has been considered and is acceptable
Closes#53175
Release Notes:
- Improves handling of indentation after C++ access modifiers
Self-Review Checklist:
- [Yes] I've reviewed my own diff for quality, security, and reliability
- [N/A] Unsafe blocks (if any) have justifying comments
- [N/A] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [N/A] Tests cover the new/changed behavior
- [N/A] Performance impact has been considered and is acceptable
Release Notes:
- N/A
Shorthand methods (`methodName() {}`) inside nested object literals were
not shown in the Outline panel. The outline query only captured
method_definition when it was a direct child of a variable_declarator's
object, so nested objects (e.g. `deep: { subFn() {} }`) were missed.
Extended the outline query to match method_definition in any object
node, not just top-level variable_declarator objects. Applied the fix to
TypeScript, JavaScript, and TSX outline definitions. Added tests for the
issue reproduction and edge cases.
Supporting evidence:
<img width="1352" height="812" alt="image"
src="https://github.com/user-attachments/assets/64868a70-abd3-4935-9c03-4c809b55262b"
/>
Fixes#48711
Release Notes:
- Fixed nested object methods not appearing in the Outline panel for
JavaScript and TypeScript files
TopoJSON is an extension of the geospatial data interchange format,
GeoJSON. Although it is not as widely popular, it is frequently used in
web maps, where its smaller file size is advantageous.
More information about TopoJSON can be found here:
https://github.com/topojson/topojson-specification
This change adds `topojson` as a recognised path suffix, so TopoJSON
files automatically open as JSON and get the standard JSON syntax
highlighting.
This PR is similar to @flother’s PR for GeoJSON:
https://github.com/zed-industries/zed/pull/49261
Closes (my own) discussion:
https://github.com/zed-industries/zed/discussions/32963
PS: This is my first PR. I'd appreciate any feedback or suggestions for
improvement
Self-Review Checklist:
- [X] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release notes:
- Added automatic syntax highlighting for TopoJSON files
Closes#4751
## Testing
- Manually tested by comparing the behaviors with vscode.
- Those requirements are added to unit tests.
Release Notes:
- Added action to toggle block comments
---------
Co-authored-by: ozacod <ozacod@users.noreply.github.com>
Syntax highlighting and its customization are very important to many
developers, including me. I've looked through a number of issues and
discussions on this topic and haven't found any active PRs. Currently,
there's no way to customize highlighting for custom JSX tags, as they
use `@type`. Since TSX has a particularly complex syntax and can often
contain types/aliases/generics/tags in a dense sequence, they all blends
into a single color and makes it difficult to "parse" by eyes.
To avoid proposing something arbitrary, I looked into how this is done
elsewhere.
- VS Code `support.class.component.tsx`
[TypeScriptReact.tmLanguage.json](724656efa2/extensions/typescript-basics/syntaxes/TypeScriptReact.tmLanguage.json (L5802))
But it relies on both legacy [tmLanguage naming
conventions](https://macromates.com/manual/en/language_grammars#:~:text=rarely%20be%20used\).-,support,-%E2%80%94%20things%20provided%20by)
and the outdated assumption that React components are always classes.
- ReScript `@tag`
[rescript-zed](b3930c1754/languages/rescript/highlights.scm (L277))
It's not entirely correct to just use a `@tag` - it's better to
distinguish JSX Intrinsic Elements from custom ones.
- Vue `@tag @tag.component.type.constructor`
[zed-extensions/vue](2697588c5c/languages/vue/highlights.scm (L9C21-L9C52))
- Svelte `@tag @tag.component.type.constructor`
[zed-extensions/svelte](ae381a1217/languages/svelte/highlights.scm (L46C21-L46C52))
The similarity between Vue and Svelte implementations (perhaps one
borrowed from the other) didn't seem coincidental and the approach felt
appropriate.
**I decided to adopt the same one to maintain consistency for theme
creators.**
So, how it looks:
**Release (0.224.9) version**
<img width="440" height="220" alt="zed-one-release"
src="https://github.com/user-attachments/assets/6f8726c5-a17e-4387-941c-69e5c1569049"
/>
**Local version with changes** - no breaking changes for builtin themes
- uses `type` color as before and can be changed in themes separately if
needed
<img width="440" height="220" alt="zed-one-local"
src="https://github.com/user-attachments/assets/a11cc5ed-20fc-45d2-8ebd-a908503999c3"
/>
**Local version with changes and theme overrides**
<img width="440" height="220" alt="zed-one-with-overrides"
src="https://github.com/user-attachments/assets/1997bd5b-7fa4-4346-8338-b5d61e9e832b"
/>
With these changes in the config:
```jsonc
"theme_overrides": {
"One Light": {
"syntax": {
// "tag.component" also matches
"type.component": {
"color": "#d3604fff",
},
},
},
},
```
I'm pretty sure this will help many developers enjoy Zed even more.
Release Notes:
- Improved syntax highlighting for custom jsx elements in TSX and
JavaScript languages. Theme authors and users can now highlight these in
their theme/theme overrides using `tag.component.jsx`
## Summary
- PR #48109 changed the capture name for C/C++ preprocessor directives
from `@keyword.directive` to `@preproc`. While semantically correct, the
builtin themes had `preproc` defined with colors nearly
indistinguishable from plain text (e.g. One Dark `#dce0e5ff`, Ayu Dark
`#bfbdb6ff`), making `#include`, `#define`, etc. appear unhighlighted.
- This PR updates the `preproc` color in all builtin themes (and the
fallback theme) to match their respective `keyword` color, restoring
visible highlighting for preprocessor directives.
Fixes#49024
## Side effects
- Go uses `@preproc` for `//go:` and `// +build` compiler directives.
These will also change from the previous muted gray to the keyword
color. This is arguably an improvement — compiler directives are special
constructs that benefit from visible highlighting, consistent with how
other editors (CLion, VS Code) handle them.
## Test plan
- [x] `cargo test -p language highlight_map` passes
- [x] Open a C/C++ file and verify `#include`, `#define`, `#ifdef`, etc.
are highlighted with the keyword color
- [x] Verify across multiple builtin themes (One Dark, Ayu Dark, Gruvbox
Dark, etc.)
- [x] Open a Go file and verify `//go:` directives are highlighted
reasonably
🤖 Generated with [Claude Code](https://claude.com/claude-code)
Release Notes:
- Fixed C/C++ preprocessor directives (`#include`, `#define`, etc.)
appearing unhighlighted in builtin themes.
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: MrSubidubi <finn@zed.dev>
## Context
<!-- What does this PR do, and why? How is it expected to impact users?
Not just what changed, but what motivated it and why this approach.
Link to Linear issue (e.g., ENG-123) or GitHub issue (e.g., Closes#456)
if one exists — helps with traceability. -->
## How to Review
<!-- Help reviewers focus their attention:
- For small PRs: note what to focus on (e.g., "error handling in
foo.rs")
- For large PRs (>400 LOC): provide a guided tour — numbered list of
files/commits to read in order. (The `large-pr` label is applied
automatically.)
- See the review process guidelines for comment conventions -->
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- Marked `.json.dist` as a `json` file
## Context
<!-- What does this PR do, and why? How is it expected to impact users?
Not just what changed, but what motivated it and why this approach.
Link to Linear issue (e.g., ENG-123) or GitHub issue (e.g., Closes#456)
if one exists — helps with traceability. -->
## How to Review
<!-- Help reviewers focus their attention:
- For small PRs: note what to focus on (e.g., "error handling in
foo.rs")
- For large PRs (>400 LOC): provide a guided tour — numbered list of
files/commits to read in order. (The `large-pr` label is applied
automatically.)
- See the review process guidelines for comment conventions -->
## Self-Review Checklist
<!-- Check before requesting review: -->
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] Unsafe blocks (if any) have justifying comments
- [ ] The content is consistent with the [UI/UX
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
- [ ] Tests cover the new/changed behavior
- [ ] Performance impact has been considered and is acceptable
Release Notes:
- Marked `.jshintrc` as a `jsonc` file
This PR removes the imports query and all surrounding support from the
language_core crate.
The imports query was experimented with during the addition of Zeta 2.
However, it has been unused for a few months now and the direction does
not seemt to be pursued anymore.
Thus, removing the support here.
Release Notes:
- N/A
This extracts a `language_core` crate from the existing `language`
crate, and creates a `grammars` data crate. The goal is to separate
tree-sitter grammar infrastructure, language configuration, and LSP
adapter types from the heavier buffer/editor integration layer in
`language`.
## Motivation
The `language` crate pulls in `text`, `theme`, `settings`, `rpc`,
`task`, `fs`, `clock`, `sum_tree`, and `fuzzy` — all of which are needed
for buffer integration (`Buffer`, `SyntaxMap`, `Outline`,
`DiagnosticSet`) but not for grammar parsing or language configuration.
Extracting the core types lets downstream consumers depend on
`language_core` without pulling in the full integration stack.
## Dependency graph after extraction
```
language_core ← gpui, lsp, tree-sitter, util, collections
grammars ← language_core, rust_embed, tree-sitter-{rust,python,...}
language ← language_core, text, theme, settings, rpc, task, fs, ...
languages ← language, grammars
```
## What moved to `language_core`
- `Grammar`, `GrammarId`, and all query config/builder types
- `LanguageConfig`, `LanguageMatcher`, bracket/comment/indent config
types
- `HighlightMap`, `HighlightId` (theme-dependent free functions
`highlight_style` and `highlight_name` stay in `language`)
- `LanguageName`, `LanguageId`
- `LanguageQueries`, `QUERY_FILENAME_PREFIXES`
- `CodeLabel`, `CodeLabelBuilder`, `Symbol`
- `Diagnostic`, `DiagnosticSourceKind`
- `Toolchain`, `ToolchainScope`, `ToolchainList`, `ToolchainMetadata`
- `ManifestName`
- `SoftWrap`
- LSP data types: `BinaryStatus`, `ServerHealth`,
`LanguageServerStatusUpdate`, `PromptResponseContext`, `ToLspPosition`
## What stays in `language`
- `Buffer`, `BufferSnapshot`, `SyntaxMap`, `Outline`, `DiagnosticSet`,
`LanguageScope`
- `LspAdapter`, `CachedLspAdapter`, `LspAdapterDelegate` (reference
`Arc<Language>` and `WorktreeId`)
- `ToolchainLister`, `LanguageToolchainStore` (reference `task` and
`settings` types)
- `ManifestQuery`, `ManifestProvider`, `ManifestDelegate` (reference
`WorktreeId`)
- Parser/query cursor pools, `PLAIN_TEXT`, point conversion functions
## What the `grammars` crate provides
- Embedded `.scm` query files and `config.toml` files for all built-in
languages (via `rust_embed`)
- `load_queries(name)`, `load_config(name)`,
`load_config_for_feature(name, grammars_loaded)`, and `get_file(path)`
functions
- `native_grammars()` for tree-sitter grammar registration (behind
`load-grammars` feature)
## Pre-cleanup (also in this PR)
- Removed unused `Option<&Buffer>` from
`LspAdapter::process_diagnostics`
- Removed unused `&App` from `LspAdapter::retain_old_diagnostic`
- Removed `fs: &dyn Fs` from `ToolchainLister` trait methods
(`PythonToolchainProvider` captures `fs` at construction time instead)
- Moved `Diagnostic`/`DiagnosticSourceKind` out of `buffer.rs` into
their own module
## Backward compatibility
The `language` crate re-exports everything from `language_core`, so
existing `use language::Grammar` (etc.) continues to work unchanged. The
only downstream change required is importing `CodeLabelExt` where
`.fallback_for_completion()` is called on the now-foreign `CodeLabel`
type.
Release Notes:
- N/A
---------
Co-authored-by: Agus Zubiaga <agus@zed.dev>
Co-authored-by: Tom Houlé <tom@tomhoule.com>
