## Add relative line numbers on wrapped lines, take 2
This is a rework of https://github.com/zed-industries/zed/pull/39268
that excludes
https://github.com/zed-industries/zed/pull/39268/commits/e7096d27a6463f6eb7c2a821637c5773b2460c10.
This commit introduced some line number rendering issues as described in
https://github.com/zed-industries/zed/issues/41422.
While @ConradIrwin suggested we try to pass in the buffer rows from the
calling method instead of the snapshot, that
appears to have had unintended consequences and I don't think the two
calculations were intended to do the same thing. Hence, this PR has
removed those changes.
This PR also includes the migration fix originally done by @MrSubidubi
in https://github.com/zed-industries/zed/pull/41351.
## Original PR description and release notes.
**Problem:** Current relative line numbering creates a mismatch with
vim-style navigation when soft wrap is enabled. Users must mentally
calculate whether target lines are wrapped segments or logical lines,
making `<n>j/k` navigation unreliable and cognitively demanding.
**How things work today:**
- Real line navigation (`j/k` moves by logical lines): Requires
determining if visible lines are wrapped segments before jumping. Can't
jump to wrapped lines directly.
- Display line navigation (`j/k` moves by display rows): Line numbers
don't correspond to actual row distances for multi-line jumps.
**Proposed solution:** Count and number each display line (including
wrapped segments) for relative numbering. This creates direct
visual-to-navigational correspondence, where the relative number shown
always matches the `<n>j/k` distance needed.
**Benefits:**
- Eliminates mental overhead of distinguishing wrapped vs. logical lines
- Makes relative line numbers consistently actionable regardless of wrap
state
- Preserves intuitive "what you see is what you navigate" principle
- Maintains vim workflow efficiency in narrow window scenarios
Also explained and discussed in
https://github.com/zed-industries/zed/discussions/25733.
Release Notes:
- Added support for counting wrapped lines as relative lines and for
displaying line numbers for wrapped segments. Changes
`relative_line_numbers` from a boolean to an enum: `enabled`,
`disabled`, or `wrapped`.
A user on Discord requested this feature:
https://discord.com/channels/869392257814519848/1434188637389717556/1434188637389717556
I added a scrollbar setting called `completion_menu_scrollbar` to the
completion menu and defaulted it to "Never" to match past behavior.
Release Notes:
- editor: Add `editor.completion_menu_scrollbar` setting to show a
scrollbar in the completion menu
Closes#41422
This completely broke line numbering as described in the linked issue
and scrolling up does not have the correct numbers any more.
Release Notes:
- NOTE: The `relative_line_numbers` change
(https://github.com/zed-industries/zed/pull/39268) was reverted and did
not make the release cut!
**Problem:** Current relative line numbering creates a mismatch with
vim-style navigation when soft wrap is enabled. Users must mentally
calculate whether target lines are wrapped segments or logical lines,
making `<n>j/k` navigation unreliable and cognitively demanding.
**How things work today:**
- Real line navigation (`j/k` moves by logical lines): Requires
determining if visible lines are wrapped segments before jumping. Can't
jump to wrapped lines directly.
- Display line navigation (`j/k` moves by display rows): Line numbers
don't correspond to actual row distances for multi-line jumps.
**Proposed solution:** Count and number each display line (including
wrapped segments) for relative numbering. This creates direct
visual-to-navigational correspondence where the relative number shown
always matches the `<n>j/k` distance needed.
**Benefits:**
- Eliminates mental overhead of distinguishing wrapped vs. logical lines
- Makes relative line numbers consistently actionable regardless of wrap
state
- Preserves intuitive "what you see is what you navigate" principle
- Maintains vim workflow efficiency in narrow window scenarios
Also explained an discussed in
https://github.com/zed-industries/zed/discussions/25733.
Release Notes:
Release Notes:
- Added support for counting wrapped lines as relative lines and for
displaying line numbers for wrapped segments. Changes
`relative_line_numbers` from a boolean to an enum: `enabled`,
`disabled`, or `wrapped`.
---------
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
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
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
Closes#5355
Release Notes:
- Fixed rendering glitches with files with more than 16 million lines
(that occured due to floating number rounding errors).
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
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>
Closes https://github.com/zed-industries/zed/issues/37621
Improves https://github.com/zed-industries/zed/issues/24623
Adding scrollbars withing Zed's UI currently is rather cumbersome, as it
requires the copying of a lot of code in order for these to work. Wiring
up settings for scrollbar visibilty always has to be done at the call
site and the state has to be saved and maintained by the caller as well.
Similarly, reserving space has to also be handled by the caller.
This PR changes the way scrollbars work in Zed fundamentally by making
use of the new `use_keyed_state` APIs: Instead of saving the state at
the call site, the window now keeps track of the state corresponding to
scrollbars. This enables us to add scrollbars with e.g. one simple call
on divs:
```rust
div()
.vertical_scrollbar(window, cx)
```
will add a scrollbar to the corresponding container. There are some more
improvements regarding tracking of scrollbar visibility settings (which
is now handled by a trait for each setting that supports this) as well
as reserving space.
Additionally, all needed stuff for layouting, catching events and
reserving space is also now managed by the scrollbar component instead.
This drastically reduces the amount of event listeners and makes
layouting of two scrollbars easier.
Furthermore, this paves the way for more improvements to scrollbars,
such as graceful auto-hide. Only downsight here is that we lose some
customizability in a few areas. However, once this lands, we gain the
ability to quickly follow these up without breaking stuff elsewhere.
This also already fixes a few bugs:
- Scrollbars no longer flicker on first render.
- Auto-hide now properly works for all scrollbars.
- If the content size changes, the scrollbar is updated on the same
frame. Both of these happened because we were computing the scrollbar
sizes too early, causing us to use the sizes from the previous frame or
unitialized sizes.
- The project panel no longer jumps if scrolled all the way to the
bottom and the scrollbar actually auto-hides.
Still TODO:
- [x] Fix scrolling in the debugger memory view
- [x] Clean up some more in the scrollbar component and reduce clones
there
- [x] Ensure we don't over-notify the entity the scrollbar is rendered
within
- [x] Make sure auto-hide properly works for all cases
- [x] Check whether we want to implement the scrollbar trait for
`UniformList`s as well
- ~~ [ ] Use for uniformlist where possible~~ Postponed
- [x] Improve layout for cases where we render both scrollbars.
Release Notes:
- N/A
This PR improves the settings_ui proc macro by taking into account more
serde attributes
1. rename_all
2. rename
3. flatten
We also pass field documentation to the UI layer now too. This allows ui
elements to have more information like the switch field description.
We got the scrollbar working and started getting language settings to
show up.
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
This PR separates out the associated constant `KEY` from the `Settings`
trait into a new trait `SettingsKey`. This allows for the key trait to
be derived using attributes to specify the path so that the new
`SettingsUi` derive macro can use the same attributes to determine top
level settings paths thereby removing the need to duplicate the path in
both `Settings::KEY` and `#[settings_ui(path = "...")]`
Co-authored-by: Ben Kunkle <ben@zed.dev>
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes #ISSUE
This PR includes the necessary work to get `EditorSettings` showing up
in the settings UI. Including making the `path` field on
`SettingsUiItem`'s optional so that top level items such as
`EditorSettings` which have `Settings::KEY = None` (i.e. are treated
like `serde(flatten)`) have their paths computed correctly for JSON
reading/updating.
It includes the first examples of a pattern I expect to continue with
the `SettingsUi` work with respect to settings reorganization, that
being adding missing defaults, and adding explicit values (or aliases)
to settings which previously relied on `null` being a value for optional
fields.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Initially, the `SettingsUi` trait was tied to `Settings`, however, given
that the `Settings::FileContent` type (which may be the same as the type
that implements `Settings`) will be the type that more directly maps to
the JSON structure (and therefore have the documentation, correct field
names (or `serde` rename attributes), etc) it makes more sense to have
the deriving of `SettingsUi` occur on the `FileContent` type rather than
the `Settings` type.
In order for this to work a relatively important change had to be made
to the derive macro, that being that it now "unwraps" options into their
inner type, so a field with type `Option<Foo>` where `Foo: SettingsUi`
will treat the field as if it were just `Foo`, expecting there to be a
default set in `default.json`. This imposes some restrictions on what
`Settings::FileContent` can be as seen in 1e19398 where `FileContent`
itself can't be optional without manually implementing `SettingsUi`, as
well as introducing some risk that if the `FileContent` type has
`serde(default)`, the default value will override the default value from
`default.json` in the UI even though it may differ (but it should!).
A future PR should probably replace the other settings with `FileContent
= Option<T>` (all of which currently have `T == bool`) with wrapper
structs and have `KEY = None` so the further niceties
`derive(SettingsUi)` will provide such as path renaming, custom UI, auto
naming and doc comment extraction can be used.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
## Goal
This PR creates the initial settings ui structure with the primary goal
of making a settings UI that is
- Comprehensive: All settings are available through the UI
- Correct: Easy to understand the underlying JSON file from the UI
- Intuitive
- Easy to implement per setting so that UI is not a hindrance to future
settings changes
### Structure
The overall structure is settings layer -> data layer -> ui layer.
The settings layer is the pre-existing settings definitions, that
implement the `Settings` trait. The data layer is constructed from
settings primarily through the `SettingsUi` trait, and it's associated
derive macro. The data layer tracks the grouping of the settings, the
json path of the settings, and a data representation of how to render
the controls for the setting in the UI, that is either a marker value
for the component to use (avoiding a dependency on the `ui` crate) or a
custom render function.
Abstracting the data layer from the ui layer allows crates depending on
`settings` to implement their own UI without having to add additional UI
dependencies, thus avoiding circular dependencies. In cases where custom
UI is desired, and a creating a custom render function in the same crate
is infeasible due to circular dependencies, the current solution is to
implement a marker for the component in the `settings` crate, and then
handle the rendering of that component in `settings_ui`.
### Foundation
This PR creates a macro and a trait both called `SettingsUi`. The
`SettingsUi` trait is added as a new trait bound on the `Settings`
trait, this allows the type system to guarantee that all settings
implement UI functionality. The macro is used to derived the trait for
most types, and can be modified through attributes for unique cases as
well.
A derive-macro is used to generate the settings UI trait impl, allowing
it the UI generation to be generated from the static information in our
code base (`default.json`, Struct/Enum names, field names, `serde`
attributes, etc). This allows the UI to be auto-generated for the most
part, and ensures consistency across the UI.
#### Immediate Follow ups
- Add a new `SettingsPath` trait that will be a trait bound on
`SettingsUi` and `Settings`
- This trait will replace the `Settings::key` value to enable
`SettingsUi` to infer the json path of it's derived type
- Figure out how to render `Option<T> where T: SettingsUi` correctly
- Handle `serde` attributes in the `SettingsUi` proc macro to correctly
get json path from a type's field and identity
Release Notes:
- N/A
---------
Co-authored-by: Ben Kunkle <ben@zed.dev>
Closes#35787Closes#17890Closes#28789Closes#36495
How it works:
For highlights (and selections) within the visible rows of the editor,
we split them row by row. This is efficient since the number of visible
rows is constant. For each row, all highlights and selections, which may
overlap, are flattened using a line sweep. This produces non-overlapping
consecutive segments for each row, each with a blended background color.
Next, for each row, we split text runs into smaller runs to adjust its
color using APCA contrast. Since both text runs and segment are
non-overlapping and consecutive, we can use two-pointer on them to do
this.
For example, a text run for the variable red might be split into two
runs if a highlight partially covers it. As a result, one part may
appear as red, while the other appears as a lighter red, depending on
the background behind it.
Result:
<img width="1458" height="949" alt="image"
src="https://github.com/user-attachments/assets/4814c93d-12e7-4b4d-8542-d912acccfb8e"
/>
<img width="1459" height="952" alt="image"
src="https://github.com/user-attachments/assets/9e497b6c-3e66-43e8-8e5b-f634dd5ee8d3"
/>
<img width="1457" height="621" alt="image"
src="https://github.com/user-attachments/assets/8dfa6ce5-f46b-45b9-8008-66169d5aecd4"
/>
Release Notes:
- Improved text contrast when selected or highlighted in the editor.
Release Notes:
- Added an option for the status_bar.cursor_position_button. Setting to
`false` will hide the button. It defaults to `true`.
This builds off the recent work to hide the language selection button
(https://github.com/zed-industries/zed/pull/33977). I tried to follow
that pattern, and to pick a clear name for the option, but any
feedback/change is welcome.
---------
Co-authored-by: zumbalogy <3770982+zumbalogy@users.noreply.github.com>
Release Notes:
- Added settings status_bar.show_active_language_button to show/hide the
language button in the status bar.
The motivation for this is visual, I have had zero issues with its
functionality.
The language switcher can still be accessed by the command palette,
menu, or a keyboard shortcut.
------
This is my first Zed and first Rust PR, so criticism is very welcome.
I know there has been discussion around how the status bar settings are
structured and named, and I am happy to change it to whatever is best. I
was also not sure what order to put it in in the settings default.json.
Feedback welcome.
Here is a picture of it in action:
---------
Co-authored-by: zumbalogy <3770982+zumbalogy@users.noreply.github.com>
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
This mirrors VSCode setting that inspired `snippet_sort_order` to begin
with; VSCode supports inline/top/bottom/none, with none completely
disabling snippet completion. See
https://code.visualstudio.com/docs/editing/intellisense#_snippets-in-suggestions
This is helpful for LSPs that do not allow configuring snippets via
configuration such as clangd.
Release Notes:
- Added `none` as one of the values for `snippet_sort_order` to
completely disable snippet completion.
When [`drag_and_drop_selection` is
true](https://zed.dev/docs/configuring-zed#drag-and-drop-selection),
users can make a selection in the buffer and then drag and drop it to a
new location. However, the editor forces users to wait 300ms after mouse
down before dragging. If users try to drag before this delay has
elapsed, they will create a new text selection instead, which can create
the impression that drag and drop does not work.
I made two changes to improve the UX of this feature:
* If users do not want a delay before drag and drop is enabled, they can
set the `drag_and_drop_selection.delay_ms` setting to 0.
* If the user has done a mouse down on a text selection, the cursor
changes to a copy affordance as soon as the configured delay has
elapsed, rather than waiting for them to start dragging. This way they
don't need to guess at when the delay has elapsed.
The default settings for this feature are now:
```
"drag_and_drop_selection": {
"enabled": true,
"delay_ms": 300
}
```
Closes#33915
Before:
https://github.com/user-attachments/assets/7b2f986f-9c67-4b2b-a10e-757c3e9c934b
After:
https://github.com/user-attachments/assets/726d0dbf-e58b-41ad-93d2-1a758640b422
Release Notes:
- Migrate `drag_and_drop_selection` setting to
`drag_and_drop_selection.enabled`.
- Add `drag_and_drop_selection.delay_ms` setting to configure the delay
that must elapse before drag and drop is allowed.
- Show a ready to drag cursor affordance as soon as the delay has
elapsed
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Closes#30017
* While generating the settings JSON schema, defaults all schema
definitions to reject unknown fields via `additionalProperties: false`.
* Uses `unevaluatedProperties: false` at the top level to check fields
that remain after the settings field names + release stage override
field names.
* Changes json schema version from `draft07` to `draft_2019_09` to have
support for `unevaluatedProperties`.
Release Notes:
- Added warnings for unknown fields when editing `settings.json`.
https://github.com/user-attachments/assets/ad0fa304-e4fb-4598-877d-c02141f35d6f
Closes https://github.com/zed-industries/zed/issues/4678
Also adds the code to support `textDocument/colorPresentation`
counterpart that serves as a resolve mechanism for the document colors.
The resolve itself is not run though, and the editor does not
accommodate color presentations in the editor yet — until a well
described use case is provided.
Use `lsp_document_colors` editor settings to alter the presentation and
turn the feature off.
Release Notes:
- Start showing inline previews for LSP document colors
Release Notes:
- Add a setting to show the minimap only on the current active editor
(file)
- This can be configured on `settings.json`:
```json
{
"minimap": {
"display_in": "active_editor", // defaults to "all_editors"
}
}
```
- The minimap won't hide if you go from an editor pane to the terminal,
the project panel, the search bar, etc. It will only hide if you go from
one editor pane to another.
Preview:
Only the active editor (left) displays the minimap.
Closes https://github.com/zed-industries/zed/issues/12091
Use `"save_non_dirty_buffers": false` editor settings to disable this
behavior.
Release Notes:
- Fixed formatting effects not triggered when saving unmodified
singleton buffers
Closes#7334
# Changes
This PR makes the minimum width allocated for line numbers in the side
gutter configurable in units of character width via the
`"line_number_base_width"` attribute in `gutter` settings. Set the
previously hard coded value of `4` as default.
Together with other settings (`"folds"`, `"breakpoints"`,...) this gives
the user control over the gutter width.
If the number of lines exceedes the base width, the number of digits in
the largest line number is chosen instead. This is consistent with
previous behaviour.
Screenshot for reference:
<img width="1104" alt="Screenshot 2025-06-03 at 12 15 29"
src="https://github.com/user-attachments/assets/77c869ad-164b-4b74-8e39-8be43d740ad4"
/>
P.S.: This is my first time contributing to zed (yay!🎉). Let me know if
i'm missing something.
Release Notes:
- Make minimum line number width in gutter configurable
Closes#4958
Release Notes:
- Added support for drag and drop text selection. It can be disabled by
setting `drag_and_drop_selection` to `false`.
---------
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Fixes#14612
This was a feature I dearly missed from VSCode, so adding this helped me
migrate to Zed without disrupting my workflow. I found that `4.0` was a
nice goldilocks multiplier and felt close/the same as the speed in
VSCode.
Release Notes:
- Added faster scrolling in the editor while holding opt/alt
Follow up to https://github.com/zed-industries/zed/pull/30140 and
https://github.com/zed-industries/zed/pull/31236
This PR introduces an inline code action indicator that shows up at the
start of a buffer line when there's enough space. If space is tight, it
adjusts to lines above or below instead. It also adjusts when cursor is
near indicator.
The indicator won't appear if there's no space within about 8 rows in
either direction, and it also stays hidden for folded ranges. It also
won't show up in case there is not space in multi buffer excerpt. These
cases account for very little because practically all languages do have
indents.
https://github.com/user-attachments/assets/1363ee8a-3178-4665-89a7-c86c733f2885
This PR also sets the existing `toolbar.code_actions` setting to `false`
in favor of this.
Release Notes:
- Added code action indicator which shows up inline at the start of the
row. This can be disabled by setting `inline_code_actions` to `false`.
* project search button in the status bar
```jsonc
"search": {
"button": false
},
```
* project diagnostics button in the status bar
```jsonc
"diagnostics": {
"button": false
}
```
* project name and host buttons in the title bar
```jsonc
"title_bar": {
"show_project_items": false
}
```
* git branch button in the title bar
```jsonc
"title_bar": {
"show_branch_name": false
}
```
Before:
<img width="1728" alt="before"
src="https://github.com/user-attachments/assets/4b13b431-3ac1-43b3-8ac7-469e5a9ccf7e"
/>
After:
<img width="1728" alt="after"
src="https://github.com/user-attachments/assets/baf2765a-e27b-47a3-8897-89152b7a7c95"
/>
Release Notes:
- Added more settings to hide buttons from Zed UI
* Adds a `diagnostics_max_severity: null` editor settings that has
previous hardcoded default, `warning`
* Make inline diagnostics to inherit this setting by default (can be
overridden with its own max_severity setting)
* Allows to toggle diagnostics in the editor menu and via new action,
`editor::ToggleDiagnostics`
Closes https://github.com/zed-industries/zed/issues/4686
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Thomas Heartman
Anthony Eid
Bob ManninoandSmit Barmase
Finn Evers
Julia Ryan
Mansoor AhmedandConrad Irwin
Piotr OsiewiczandSmit Barmase
Ivan Trubach
Mikayla Maki
zumbalogyandzumbalogy
Arseny Kapoulkine
Daniel SaubleandSmit Barmase
Michael Sloan
Evan Simkowitz
Alvaro Parker
Max Mynter
CharlesChen0823andSmit Barmase
Richard FeldmanandSmit Barmase
Alistair Smith
Finn Evers