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>
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 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.
Support to show diagnostics on the tab switcher in the same way they are
displayed on the tab bar. This follows the setting
`tabs.show_diagnostics`.
This will improve user experience when disabling the tab bar and still
being able to see the diagnostics when switching tabs
Preview:
<img width="768" height="523" alt="Screenshot From 2025-07-16 11-02-42"
src="https://github.com/user-attachments/assets/308873ba-0458-485d-ae05-0de7c1cdfb28"
/>
Release Notes:
- Added diagnostics indicators to the tab switcher
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Introduce `min_words_query_len` threshold for automatic word completion
display, and set it to 3 by default.
Re-enable word completions in Markdown and Plaintext.
Release Notes:
- Introduced `min_words_query_len` threshold for automatic word
completion display, and set it to 3 by default to make them less
intrusive
PR #20198, "Do not alter soft wrap based on .editorconfig contents"
removed support for setting line lengths for both soft and hard wrap,
not just soft wrap. This causes the `max_line_length` property within a
`.editorconfig` file to be ignored by Zed. This commit restores allowing
for hard wrap limits to be set using `max_line_length` without impacting
soft wrap limits. This is done by merging the `max_line_length` property
from an editorconfig file into Zed's `preferred_line_length` property.
Release Notes:
- Added support for .editorconfig's `max_line_length` property
Signed-off-by: Ryan Drew <git@ry4n.me>
This removes around 900 unnecessary clones, ranging from cloning a few
ints all the way to large data structures and images.
A lot of these were fixed using `cargo clippy --fix --workspace
--all-targets`, however it often breaks other lints and needs to be run
again. This was then followed up with some manual fixing.
I understand this is a large diff, but all the changes are pretty
trivial. Rust is doing some heavy lifting here for us. Once I get it up
to speed with main, I'd appreciate this getting merged rather sooner
than later.
Release Notes:
- N/A
- Correctly pre-allocate `Vec` when deserializing regexes
- Simplify manual `Vec::with_capacity` calls by using `Iterator::unzip`
- Collect directly into `Arc<[T]>` (uses `Vec` internally anyway, but
simplifies code)
- Remove unnecessary `LazyLock` around Atomics by not using const
incompatible `Default` for initialization.
Release Notes:
- N/A
Closes https://github.com/zed-industries/zed/issues/11780
While auto indentation is generally nice to have, there are cases where
it is currently just not good enough for some languages (e.g. Haskell)
or users just straight up do not want their editor to auto indent for
them. Hence, this PR adds the possibilty to disable auto indentation for
either all language or on a per-language basis. Manual invocation via
the `editor: auto indent` action will continue to work.
Also takes a similar approach as
https://github.com/zed-industries/zed/pull/31569 to ensure performance
is fine for larger multicursor edits.
Release Notes:
- Added the possibility to configure auto indentation for all languages
and per language. Add `"auto_indent": false"` to your settings or
desired language to disable the feature.
- **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>
This PR adds preliminary git clone support through using the new
`GitClone` action. This works with SSH connections too.
- [x] Get backend working
- [x] Add a UI to interact with this
Future follow-ups:
- Polish the UI
- Have the path select prompt say "Select Repository clone target"
instead of “Open”
- Use Zed path prompt if the user has that as a setting
- Add support for cloning from a user's GitHub repositories directly
Release Notes:
- Add the ability to clone remote git repositories through the `git:
Clone` action
---------
Co-authored-by: hpmcdona <hayden_mcdonald@brown.edu>
This PR changes the signature of `language_names` from
```rust
pub fn language_names(&self) -> Vec<String>
// Into
pub fn language_names(&self) -> Vec<LanguageName>
```
The function previously eagerly converted `LanguageName`'s to
`String`'s, which requires the reallocation of all of the elements. The
functions get called in many places in the code base, but only one of
which actually requires the conversion to a `String`. In one case it
would do a `SharedString` -> `String` -> `SharedString` conversion,
which is now totally bypassed.
Release Notes:
- N/A
Before, each time any LSP feature was used on client remote, it always
produced a `proto::` request that always had been sent to the host, from
where returned as an empty response.
Instead, propagate more language server-related data to the client,
`lsp::ServerCapability`, so Zed client can omit certain requests if
those are not supported.
On top of that, rework the approach Zed uses to query for the data
refreshes: before, editors tried to fetch the data when the server start
was reported (locally and remotely).
Now, a later event is selected: on each `textDocument/didOpen` for the
buffer contained in this editor, we will query for new LSP data, reusing
the cache if needed.
Before, servers could reject unregistered files' LSP queries, or process
them slowly when starting up.
Now, such refreshes are happening later and should be cached.
This requires a collab DB change, to restore server data on rejoin.
Release Notes:
- Fixed excessive LSP requests sent during remote sessions
This is a bit of a readability improvement IMHO; I often find myself
confused when dealing when dimension pairs, as there's no easy way to
jump to the implementation of a dimension for tuples to remind myself
for the n-th time how exactly that impl works. Now it should be possible
to jump directly to that impl.
Another bonus is that Dimension supports 3-ary tuples as well - by using
a () as a default value of a 3rd dimension.
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>
As suggested in https://github.com/zed-industries/zed/pull/34418, this
proposes various changes to language configs to make block comments and
doc-block-style comments more similar. In doing so, it introduces some
breaking changes into the extension schema.
This change is needed to support the changes I'm working on in #34418,
to be able to support `rewrap` in block comments like `/* really long
comment ... */`. As is, we can do this in C-style doc-block comments (eg
`/** ... */`) because of the config in `documentation`, but we can't do
this in regular block comments because we lack the info about what the
line prefix and indentation should be.
And while I was here, I did various other clean-ups, many of which feel
nice but are optional.
I would love special attention on the changes to the schema, version and
related changes; I'm totally unfamiliar with that part of Zed.
**Summary of changes**
- break: changes type of `block_comment` to same type as
`documentation_comment` (**this is the important change**)
- break: rename `documentation` to `documentation_comment` (optional,
but improves consistency w/ `line_comments` and `block_comment`)
- break/refactor?: removes some whitespace in the declaration of
`block_comment` delimiters (optional, may break things, need input; some
langs had no spaces, others did)
- refactor: change `tab_size` from `NonZeroU32` to just a `u32` (some
block comments don't seem to need/want indent past the initial
delimiter, so we need this be 0 sometimes)
- refactor: moves the `documentation_comment` declarations to appear
next to `block_comment`, rearranges the order of the fields in the TOML
for `documentation_comment`, rename backing `struct` (all optional)
**Future scope**
I believe that this will also allow us to extend regular block comments
on newline – as we do doc-block comments – but I haven't looked into
this yet. (eg, in JS try pressing enter in both of these: `/* */` and
`/** */`; the latter should extend w/ a `*` prefixed line, while the
former does not.)
Release Notes:
- BREAKING CHANGE: update extension schema version from 1 to 2, change
format of `block_comment` and rename `documentation_comment`
/cc @smitbarmase
This gets rid of the need to pass context to all cursor functions. In
practice context is always immutable when interacting with cursors.
A nicety of this is in the follow-up PR we will be able to implement
Iterator for all Cursors/filter cursors (hell, we may be able to get rid
of filter cursor altogether, as it is just a custom `filter` impl on
iterator trait).
Release Notes:
- N/A
Closes#31917
Previously, as of #28457 we used a hack, creating an empty transaction
in the history that we then merged formatting changes into in order to
correctly identify concurrent edits to the buffer while formatting was
happening. This caused issues with noop formatting however, as using the
normal API of the buffer history (in an albeit weird way) resulted in
the redo stack being cleared, regardless of whether the formatting
transaction included edits or not, which is the correct behavior in all
other contexts.
This PR fixes the redo issue by codifying the behavior formatting wants,
that being the ability to push an empty transaction to the history with
no other side-effects (i.e. clearing the redo stack) to detect
concurrent edits, with the tradeoff being that it must then manually
remove the transaction later if no changes occurred from the formatting.
The redo stack is still cleared when there are formatting edits, as the
individual format steps use the normal `{start,end}_transaction` methods
which clear the redo stack if the finished transaction isn't empty.
Release Notes:
- Fixed an issue where redo would not work after buffer formatting
(including formatting on save) when the formatting did not result in any
changes
Closes#33510https://github.com/zed-extensions/php/issues/29
If certain language servers do not provide an insert/replace range, we
use `surrounding_word` as a fallback for that range, which internally
uses `word_characters`. It makes sense to use
`completion_query_characters` instead of `word_characters` to get that
range, because we use `completion_query_characters` to query completions
in the first place.
That means, for some hypothetical reason (e.g., if the Tailwind server
stops providing insert/replace ranges), we would correctly fall back to
the range "bg-blue-200^" instead of "200^", because
`completion_query_characters` includes "-" in this case.
For this particular fix, right now the default PHP language server
`phpactor` does not provide an insert/replace range, and hence
completion query character is used, which is `$` in this case.
Note that `$` isn't in word characters for reasons mentioned here:
https://github.com/zed-extensions/php/issues/14
Release Notes:
- Fixed an issue where accepting variable completion in PHP would result
in a double $ sign in the prefix.
Followup to #33678, doing the same thing for all JSON Schema files
provided to json-language-server
Release Notes:
* Added warnings for unknown fields when editing `tasks.json` /
`snippets.json`.
Closes#19644#18151
Now, rewrapping markdown lists (unordered, ordered, and to-do lists) and
block quotes wrap them separately, without merging them together.
Additionally, it correctly indents subsequent lines.
With this input:
```md
1. This is a list item that is short.
2. This list item is a bit longer because I want to see if it wraps correctly after a rewrap operation in Zed. What do you think?
3. another short item
```
Output would be:
```md
1. This is a list item that is short.
2. This list item is a bit longer because I want to see if it wraps correctly
after a rewrap operation in Zed. What do you think?
3. another short item
```
Instead of:
```md
1. This is a list item that is short. 2. This list item is a bit longer because
I want to see if it wraps correctly after a rewrap operation in Zed. What
do you think? 3. another short item
```
Release Notes:
- Improved rewrap for markdown lists, todos, and block quotes.
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`.
The major change in schemars 1.0 is that now schemas are represented as
plain json values instead of specialized datatypes. This allows for more
concise construction and manipulation.
This change also improves how settings schemas are generated. Each top
level settings type was being generated as a full root schema including
the definitions it references, and then these were merged. This meant
generating all shared definitions multiple times, and might have bugs in
cases where there are two types with the same names.
Now instead the schemar generator's `definitions` are built up as they
normally are and the `Settings` trait no longer has a special
`json_schema` method. To handle types that have schema that vary at
runtime (`FontFamilyName`, `ThemeName`, etc), values of
`ParameterizedJsonSchema` are collected by `inventory`, and the schema
definitions for these types are replaced.
To help check that this doesn't break anything, I tried to minimize the
overall [schema
diff](https://gist.github.com/mgsloan/1de549def20399d6f37943a3c1583ee7)
with some patches to make the order more consistent + schemas also
sorted with `jq -S .`. A skim of the diff shows that the diffs come
from:
* `enum: ["value"]` turning into `const: "value"`
* Differences in handling of newlines for "description"
* Schemas for generic types no longer including the parameter name, now
all disambiguation is with numeric suffixes
* Enums now using `oneOf` instead of `anyOf`.
Release Notes:
- N/A
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.
## Context
To support inline values a language will have to implement their own
provider trait that walks through tree sitter nodes. This is overly
complicated, hard to accurately implement for each language, and lacks
proper extension support.
This PR switches to a singular inline provider that uses a language's
`debugger.scm` query field to capture variables and scopes. The inline
provider is able to use this information to generate inlays that take
scope into account and work with any language that defines a debugger
query file.
### Todos
- [x] Implement a utility test function to easily test inline values
- [x] Generate inline values based on captures
- [x] Reimplement Python, Rust, and Go support
- [x] Take scope into account when iterating through variable captures
- [x] Add tests for Go inline values
- [x] Remove old inline provider code and trait implementations
Release Notes:
- debugger: Generate inline values based on a language debugger.scm file
This PR addresses to fix (#31308) a race condition where auto-indent (in
buffer.cs) and on-type-formatting (in lsp_store.rs) concurrently
calculate indentation using the same buffer snapshot.
Previous Solution (Abandoned):
https://github.com/zed-industries/zed/pull/31340
Final Solution:
Delay applying on-type-formatting until auto-indent is complete.
Issue:
If AutoindentMode finishes first, formatting works correctly. If
"Formatting on typing" starts before AutoindentMode completes, it
results in double indentation.
Closes#31308
Release Notes:
- Fixed a race condition resulting in incorrect buffer contents when combining auto-indent and on-type-formatting
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.
Todo:
* [x] Open diffed files as regular buffers
* [x] Update diff when buffers change
* [x] Show diffed filenames in the tab title
* [x] Investigate why syntax highlighting isn't reliably handled for old
text
* [x] remove unstage/restore buttons
Release Notes:
- Adds `zed --diff A B` to show the diff between the two files
---------
Co-authored-by: Max Brunsfeld <maxbrunsfeld@gmail.com>
Co-authored-by: Ben Brandt <benjamin.j.brandt@gmail.com>
Co-authored-by: Agus Zubiaga <agus@zed.dev>
