This PR makes editor diff hunk colors configurable from themes, instead
of hardcoded values.
It introduces 6 new optional theme keys:
- `editor.diff_hunk.added.background`
- `editor.diff_hunk.added.hollow_background`
- `editor.diff_hunk.added.hollow_border`
- `editor.diff_hunk.deleted.background`
- `editor.diff_hunk.deleted.hollow_background`
- `editor.diff_hunk.deleted.hollow_border`
When a theme omits these keys, each color falls back to the existing
version-control color with the previous hardcoded opacity values:
- Light defaults:
- background_opacity = 0.16
- hollow_background_opacity = 0.08
- hollow_border_opacity = 0.48
- Dark defaults:
- background_opacity = 0.12
- hollow_background_opacity = 0.06
- hollow_border_opacity = 0.36
There is an existing feature request
https://github.com/zed-industries/zed/discussions/51667
## Screenshots
I used `Modus Themes` (Modus Vivendi) since these themes provide highly
accessible themes.
Original version:
<img width="3248" height="2120" alt="CleanShot 2026-03-17 at 20 26
41@2x"
src="https://github.com/user-attachments/assets/730be802-835d-436e-a1fc-4c60dcb5fce8"
/>
This version:
<img width="3248" height="2120" alt="CleanShot 2026-03-17 at 20 23
09@2x"
src="https://github.com/user-attachments/assets/785c86d3-147e-437f-9624-9576bc201551"
/>
Before you mark this PR as ready for review, make sure that you have:
- [x] Added a solid test coverage and/or screenshots from doing manual
testing
- [x] Done a self-review taking into account security and performance
aspects
- [x] Aligned any UI changes with the [UI
checklist](https://github.com/zed-industries/zed/blob/main/CONTRIBUTING.md#uiux-checklist)
Release Notes:
- Added theme keys for configuring editor diff hunk colors.
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
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
# Helix Amp Jump Navigation
## Overview
Implements Helix-style "amp jump" (`g w`) navigation for jump-to-word
functionality. This feature displays two-character labels on each word
in the visible area, allowing users to quickly jump to any word by
typing its label. Labels alternate between forward and backward
directions (same algorithm as in the Helix) from the cursor position,
giving closer jump targets easier-to-type labels.
## Context
- **Request:** Implement "amp jump" navigation similar to Helix editor's
jump-to-word feature.
- **Scope:** Full implementation including label generation, UI
rendering, and input handling.
- **Inspiration:** Helix editor's "amp jump" and vim-easymotion/hop.nvim
plugins.
## How It Works
1. Press `g w` to activate "amp jump"
2. Two-character labels appear on all words in visible area
3. User types the two-character label shown on the target word
4. Cursor jumps to that word
Release Notes:
- Added in Helix mode the "amp jump" navigation (`g w`) that displays
two-character labels on words for quick cursor navigation. Labels
alternate between forward and backward directions from the cursor,
prioritizing closer targets with easier-to-type labels. The color of the
labels can be controlled via a new `helix.jump_label_accent` setting
---------
Co-authored-by: Jakub Konka <kubkon@jakubkonka.com>
See:
626cf8e761/languages/mlx/config.toml (L3)
Self-Review Checklist:
- [x] I've reviewed my own diff for quality, security, and reliability
- [ ] 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:
- Associate .mlx extensions with OCaml
Remove the standalone storybook binary and the story crate, as component
previews are now handled by the component_preview crate.
Also removes the stories features from the ui and title_bar crates.
Release Notes:
- N/A or Added/Fixed/Improved ...
When filtering themes with a query that matches nothing (e.g., "zzz"),
`show_selected_theme` returned `None` and overwrote `selected_theme`.
Clearing the filter then lost track of the previous selection and
defaulted to index 0.
The fix only updates `selected_theme` when `show_selected_theme` returns
`Some`. Same change in both the theme selector and the icon theme
selector.
## Context
When `update_matches` runs a filter that yields zero results,
`show_selected_theme` returns `None`. The old code unconditionally
assigned that back to `selected_theme`, wiping out the previous
selection. When the user clears the filter, the selector falls into the
`query.is_empty() && selected_theme.is_none()` branch and resets to
index 0 instead of restoring the original pick.
## Demo
### Before:
https://github.com/user-attachments/assets/62b1531b-d059-4f30-b1f4-a830f2d13a09
### After:
https://github.com/user-attachments/assets/72348666-8dbb-4f35-9446-fa2618340b6c
## How to review
The fix is the same one-line change in two files:
1. `crates/theme_selector/src/theme_selector.rs` — line 458
2. `crates/theme_selector/src/icon_theme_selector.rs` — line 272
The rest is test infrastructure:
3. `crates/theme/src/registry.rs` — `register_test_themes` /
`register_test_icon_themes` helpers
4. Tests in both selector files covering the empty filter → clear filter
flow
## 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
## Release notes
- Fixed theme selector losing the selected theme after filtering with a
query that matches nothing and then clearing the filter.
## 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>
Extract `SyntaxTheme` into its own lightweight crate so that downstream
consumers can use syntax highlighting colors without pulling in the full
`theme` crate and its transitive dependencies.
## Changes
**Commit 1 — Extract SyntaxTheme into its own crate**
Move `SyntaxTheme`, `SyntaxThemeSettings`, `HighlightStyle`, and
supporting types from `theme/src/styles/syntax.rs` into a new
`syntax_theme` crate that depends only on `gpui`. The `theme` crate
re-exports everything for backward compatibility — no call-site changes
needed.
**Commit 2 — Add `bundled-themes` feature with One Dark**
Add an optional `bundled-themes` feature that bundles `one_dark()`, a
`SyntaxTheme` loaded from the existing One Dark JSON theme file. This
lets consumers get a usable syntax theme without depending on the full
theme machinery.
Release Notes:
- N/A
This will allow us to use UI crate on the web
Self-Review Checklist:
- [ ] 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
Closes #ISSUE
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Self-Review Checklist:
- [ ] 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
Closes #ISSUE
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>
This PR refactors the highlight map capture name resolution to be faster
and more predictable. Speficically,
- it changes the capture name matching to explicit prefix matching
(e.g., `function.call.whatever.jsx` will now be matched by only
`function`, `function.call`, `function.call.whatever` and
`function.call.whatever.jsx`). This matches the behavior VSCode has
- resolving highlights is now much more efficient, as we now look up
captures in a BTreeMap as opposed to searching in a Vector for these.
This substantially improves the performance for resolving capture names
against themes. With the benchmark added here for creating the
HighlightMap, we see quite some improvements:
```
Running benches/highlight_map.rs (target/release/deps/highlight_map-f99da68650aac85b)
HighlightMap::new/small_captures/small_theme
time: [161.90 ns 162.70 ns 163.55 ns]
change: [-39.027% -38.352% -37.742%] (p = 0.00 < 0.05)
Performance has improved.
Found 3 outliers among 100 measurements (3.00%)
3 (3.00%) high mild
HighlightMap::new/small_captures/large_theme
time: [231.37 ns 233.02 ns 234.70 ns]
change: [-91.570% -91.516% -91.464%] (p = 0.00 < 0.05)
Performance has improved.
HighlightMap::new/large_captures/small_theme
time: [991.82 ns 994.94 ns 998.50 ns]
change: [-50.670% -50.443% -50.220%] (p = 0.00 < 0.05)
Performance has improved.
Found 5 outliers among 100 measurements (5.00%)
5 (5.00%) high mild
HighlightMap::new/large_captures/large_theme
time: [1.6528 µs 1.6650 µs 1.6784 µs]
change: [-91.684% -91.637% -91.593%] (p = 0.00 < 0.05)
Performance has improved.
Found 1 outliers among 100 measurements (1.00%)
1 (1.00%) low mild
```
For large themes and many capture names, the revised approach is much
faster.
With that in place, we can also add better fallbacks whenever we change
tokens, since e.g. a change from `@variable` to `@preproc` would
previously cause tokens to not be highlighted at all, whereas now we can
add fallbacks for such cases more efficiently. I'll add this later on to
this PR.
## 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)
- [X] Tests cover the new/changed behavior
- [X] Performance impact has been considered and is acceptable
Release Notes:
- Improved resolution speed of theme highlight capture names. This might
change highlighting in some rare edge cases, but should overall make
highlighting more predicatable. Theme captures will now follow a strict
prefix matching, so e.g. function.call.decorator.jsx` will now be
matched by only `function`, `function.call`, `function.call.decorator`
and `function.call.decorator.jsx` with the most specific capture always
taking precedence.
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Co-authored-by: Gaauwe Rombouts <mail@grombouts.nl>
- zed-extensions/elixir#61 renames `HEEX` to `HEEx`; to prevent any
disruptions from that change, this adds the correct name alongside a
settings migration
- zed-extensions/elixir#101 adds support for `EEx` templates; this sets
the default language server to be the same as that of `Elixir` and
`HEEx`
This also adds a few more extensions that should be recognized as `HEEx`
files
Release Notes:
- N/A
---------
Co-authored-by: Finn Evers <finn@zed.dev>
Mentioned in #47258
Release Notes:
- Added hotkey options and actions for toggling light and dark theme.
- Add default keymap as `cmd/ctrl+k cmd/ctrl+shift+t`
`.cppm` is the widely used extension for C++20 module interface units,
supported by MSVC, Clang, and GCC. Currently Zed doesn't recognize it as
C++, so users get no syntax highlighting or LSP support.
Changes:
`crates/languages/src/cpp/config.toml`: add cppm to path_suffixes
`crates/theme/src/icon_theme.rs`: add cppm to the C++ icon matcher
https://github.com/search?q=path%3A*.cppm&type=code
Release Notes:
- N/A
* Add a dedicated `vim.yank.background` theme color for the yank
highlight, which was previously hardcoded to
`editor.document_highlight.read_background`.
* When a theme doesn't define `vim.yank.background`, it falls back to
`editor.document_highlight.read_background` for backwards
compatibility.
* The VS Code theme importer maps `editor.rangeHighlightBackground` to
this new color.
Release Notes:
- Added configurable `vim.yank.background` theme color for vim yank
background highlight
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
The binary search insertion scheme in `highlight_text` works fine for
small numbers of elements but does not handle large amounts of ranges
well, as that will cause constant memcpying of the latter half of the
vec. Bracket colorization tends to have a huge amount of entries though,
so this can cause massive lags on the foreground thread. The better
approach here is to just collect all elements and re-sort them once.
Release Notes:
- Reduced mini-stutters occuring due to large amount of bracket
colorization in big buffers and agent diffs
Part of #7450
Big thanks to @macmv for pushing this forwards so much!
Rebased version of https://github.com/zed-industries/zed/pull/39539 as
working on an in-org branch simplifies a lot of things for us)
Release Notes:
- Added LSP semantic tokens highlighting support
---------
Co-authored-by: Neil Macneale V <neil.macneale.v@gmail.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
- Keyboard navigation where you can traverse through cells using up and
down arrow
- Jupyter Logo added
- Initialize kernel as shutdown for more predictable behavior
- Ability to create .ipynb files with bare essential metadata.
- Optimize editor initialization to avoid cloning the entire notebook
and shortcuts
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Expanded the nim entry to include `nims` and `nimble` files
- [nims](https://nim-lang.org/docs/nims.html) is a subscript of Nim that
runs in a VM
- [nimble](https://github.com/nim-lang/nimble) files are project files
for Nim that are written in Nim
Release Notes:
- Updated Nim file aliases so icon is shown for nims/nimble files
Closes #ISSUE
Moves the settings content definitions into their own crate, so that
they are compiled+cached separately from settings, primarily to avoid
recompiles due to changes in gpui. In that vain many gpui types such as
font weight/features, and `SharedString` were replaced in the content
crate, either with `*Content` types for font/modifier things, or
`String`/`Arc<str>` for `SharedString`. To make the conversions easy a
new trait method in the settings crate named `IntoGpui::into_gpui`
allows for `into()` like conversions to the gpui types in
`from_settings` impls.
Release Notes:
- N/A
---------
Co-authored-by: Piotr Osiewicz <24362066+osiewicz@users.noreply.github.com>
Closes https://github.com/zed-industries/zed/issues/44091
The issue here was that we were missing a proper default for
`ThemeSelection`. This is a disadvantage of not having the defaults in
code but actually in the `default.json`, so this here basically copies
the default from the `default.json` into code for the settings UI to
work properly.
Release Notes:
- Fixed an issue where the theme was not configurable from the settings
UI if no theme was configured prior.
Tracking Issue (does not close):
https://github.com/zed-industries/zed/issues/35552
This is somewhat of a blocker for
https://github.com/zed-industries/zed/pull/40035 (but also the current
behavior doesn't really make sense).
The current behavior of `ThemeSelectorDelegate::set_theme` (the theme
selector menu) is to simply set the in-memory settings to `Static`,
regardless of if it is currently `Dynamic`. The reason this doesn't
matter now is that the `theme::set_theme` function that updates the
user's settings file _will_ make this check, so dynamic settings stay
dynamic in `settings.json`, but not in memory.
But this is also sort of strange, because `theme::set_theme` will set
the setting of whatever the old appearance was to the new theme name. In
other words, if I am currently on a light mode theme and I change my
theme to a dark mode theme using the theme selector, the `light` field
of `theme` in `settings.json` is set to a dark mode theme!
_I think this is because displaying the new theme in the theme selector
does not update the global context, so
`ThemeSettings::get_global(cx).theme.name(appearance).0` returns the
original theme appearance, not the new one._
---
This PR makes `ThemeSelectorDelegate::set_theme` keep the current
`ThemeSelection`, as well as changes the behavior of the
`theme::set_theme` call to always choose the correct setting to update.
One edge case that might be slightly strange now is that if the user has
specified the mode as `System`, this will now override that with the
appearance of the new theme. I think this is fine, as otherwise a user
might set a dark theme and nothing will change because the
`ThemeAppearanceMode` is set to `light` or `system` (where `system` is
also light).
I also have an `unreachable!` in there that I'm pretty sure is true but
I don't really know how to formally prove that...
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
This PR adds word/character diff for expanded diff hunks that have both
a deleted and added section, as well as a setting `word_diff_enabled` to
enable/disable word diffs per language.
- `word_diff_enabled`: Defaults to true. Whether or not expanded diff
hunks will show word diff highlights when they're able to.
### Preview
<img width="1502" height="430" alt="image"
src="https://github.com/user-attachments/assets/1a8d5b71-449e-44cd-bc87-d6b65bfca545"
/>
### Architecture
I had three architecture goals I wanted to have when adding word diff
support:
- Caching: We should only calculate word diffs once and save the result.
This is because calculating word diffs can be expensive, and Zed should
always be responsive.
- Don't block the main thread: Word diffs should be computed in the
background to prevent hanging Zed.
- Lazy calculation: We should calculate word diffs for buffers that are
not visible to a user.
To accomplish the three goals, word diffs are computed as a part of
`BufferDiff` diff hunk processing because it happens on a background
thread, is cached until the file is edited, and is only refreshed for
open buffers.
My original implementation calculated word diffs every frame in the
Editor element. This had the benefit of lazy evaluation because it only
calculated visible frames, but it didn't have caching for the
calculations, and the code wasn't organized. Because the hunk
calculations would happen in two separate places instead of just
`BufferDiff`. Finally, it always happened on the main thread because it
was during the `EditorElement` layout phase.
I used Zed's
[`diff_internal`](02b2aa6c50/crates/language/src/text_diff.rs (L230-L267))
as a starting place for word diff calculations because it uses
`Imara_diff` behind the scenes and already has language-specific
support.
#### Future Improvements
In the future, we could add `AST` based word diff highlights, e.g.
https://github.com/zed-industries/zed/pull/43691.
Release Notes:
- git: Show word diff highlight in expanded diff hunks with less than 5
lines.
- git: Add `word_diff_enabled` as a language setting that defaults to
true.
---------
Co-authored-by: David Kleingeld <davidsk@zed.dev>
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
There was a TODO in `crates/settings/src/settings_content/theme.rs` to
make this rename.
This PR is just splitting off this change from
https://github.com/zed-industries/zed/pull/40035 to make reviewing that
one a bit easier since that PR is a bit more involved than expected.
Release Notes:
- N/A
Signed-off-by: Connor Tsui <connor.tsui20@gmail.com>
Follow-up: https://github.com/zed-industries/zed/pull/34655
We should use an opaque fallback color for `panel.overlay_hover`. This
helps when a custom theme doesn’t provide it, nor `element.hover`. For
example, VSCode’s default modern dark theme doesn’t include an
`element.hover` color after import.
Release Notes:
- Fixed an issue where the project panel’s sticky entry could appear
transparent on hover with certain themes.
We've been considering removing workspace-hack for a couple reasons:
- Lukas ran into a situation where its build script seemed to be causing
spurious rebuilds. This seems more likely to be a cargo bug than an
issue with workspace-hack itself (given that it has an empty build
script), but we don't necessarily want to take the time to hunt that
down right now.
- Marshall mentioned hakari interacts poorly with automated crate
updates (in our case provided by rennovate) because you'd need to have
`cargo hakari generate && cargo hakari manage-deps` after their changes
and we prefer to not have actions that make commits.
Currently removing workspace-hack causes our workspace to grow from
~1700 to ~2000 crates being built (depending on platform), which is
mainly a problem when you're building the whole workspace or running
tests across the the normal and remote binaries (which is where
feature-unification nets us the most sharing). It doesn't impact
incremental times noticeably when you're just iterating on `-p zed`, and
we'll hopefully get these savings back in the future when
rust-lang/cargo#14774 (which re-implements the functionality of hakari)
is finished.
Release Notes:
- N/A
A small follow-up to the settings refactor of a few weeks ago to move
all the VSCode settings imports
to one place.
This should make it easier to spot missing imports, and easier to test
the importer.
Release Notes:
- N/A
This PR primarily does two things:
- replace `serde_json::from_reader` with `serde_json::from_slice`, as
the latter is much much faster, even with loading the file into memory
first.
- runs the initial loading of themes and icon themes coming from
extensions in parallel instead of sequential.
Measuring the `eager_load_active_theme_and_icon_theme` method, this
drastically improves the speed at which this happens (tested this method
primarily with debug builds on my MacBook Pro, but the `Before`
measurement was also confirmed against a `release-fast` build):
- Before: ~260ms on average (in one run, it even took 600ms)
- After: ~20ms on average
Which reduces the time this method takes to load these by around ~92%.
Given that we block on this during the initial app startup, this should
drastically improve Zeds initial startup loading time. Yet, it also
improves responsiveness when installing theme extensions and trying
these.
I also replaced all other `serde_json::from_reader` implementations with
`serde_json::from_slice` and added the former to `disallowed_methods`,
given
https://github.com/serde-rs/json/issues/160#issuecomment-253446892.
Release Notes:
- Improved Zed startup speed when using themes provided by extensions
Closes https://github.com/zed-industries/zed/issues/39259
- Fixes import of `editor.fontFamily` (we were looking for the wrong
key)
- Adds basic support for the CSS font-family syntax used by VS Code,
including font fallback
Release Notes:
- N/A
Follow up to https://github.com/zed-industries/zed/pull/39468.
Unlike `agent_ui_font_size`, the `agent_buffer_font_size` setting does
have a default value, which means it does not fall back to the regular
UI font size, but rather to its default value.
Release Notes:
- N/A
Before this change the active theme and icon theme were retrofitted onto
the ThemeSettings.
Now they're in their own new global (GlobalTheme::theme(cx) and
GlobalTheme::icon_theme(cx))
This lets us remove cx from the settings traits, and tidy up a few other
things along the way.
Release Notes:
- N/A
This PR adds the numeric stepper component to the settings ui and
implements some settings that rely on this component as well.
I also switched {buffer/ui}_font_weight to the `gpui::FontWeight` type
and added a manual implementation of the Schemars trait. This allows Zed
to send min, max, and default information to the JSON LSP when a user is
manually editing the settings file.
The numeric stepper elements added to the settings ui are below:
- ui font size
- ui font weight
- Buffer font size
- Buffer font weight
- Scroll sensitivity
- Fast scroll sensitivity
- Vertical scroll margin
- Horizontal scroll margin
- Inline blame padding
- Inline blame delay
- Inline blame min column
- Unnecessary code fade
- Tab Size
- Hover popover delay
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/39406
Follow up to https://github.com/zed-industries/zed/pull/38726
This PR introduces the `agent_buffer_font_size` setting and renames
`agent_font_size` to `agent_ui_font_size`. This allows whoever wants
`buffer_font_size` and `agent_buffer_font_size` to match, as well as
folks who want a slightly smaller size only in the agent panel (which...
also looks just better by default!).
Release Notes:
- agent: Introduced the `agent_buffer_font_size` setting and renamed
`agent_font_size` to `agent_ui_font_size`, allowing for granular buffer
font size control in the agent panel vs. regular editors.
