Reverts zed-industries/zed#41384
The branch-protection rules work much better when there is a Job that
runs every time and can be depended on to pass, we no longer have this.
Release Notes:
- N/A
Follow up for: #41304
Splits CI tests (cherry-picks and PRs only for now) into separate
workflows using `gh-workflow`. Includes a couple restructures to
- run more things in parallel
- remove our previous shell script based checking to filter tests based
on files changed, instead using the builtin `paths:` workflow filters
Splitting the docs/style/rust tests & checks into separate workflows
means we lose the complete summary showing all the tests in one view,
but it's possible to re-add in the future if we go back to checking what
files changed ourselves or always run everything.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Conrad <conrad@zed.dev>
Closes#40898
Release Notes:
- Fixed an issue where attempting to add or update a key binding in the
keymap editor with an empty `keymap.json` file would fail
Closes#40874
Release Notes:
- Fixed an issue where migrating settings after v0.208.5+ would
spuriously enable prettier. This fix only affects those who have not
updated or migrated yet. For those who have already updated to version
v0.208.5 or later, placing `"formatter": []` in your settings in the
affected languages will fix the issue.
---------
Co-authored-by: Mikayla <mikayla@zed.dev>
Closes#40608
Release Notes:
- settings_ui: Fixed an issue where tabbing to the nav bar from the
search bar while the nav bar was scrolled would result in the first
_visible_ nav entry being selected, instead of the literal first nav
entry
- settings_ui: Fixed an issue where scrolling the selected nav entry off
screen would cause the keyboard shortcut hint for the focus nav / focus
content binding to dissapear
- settings_ui: Fixed an issue where text input controls could not be
focused via the keyboard
Closes #ISSUE
Adds a `Maybe<T>` type to `settings_content`, that makes the distinction
between `null` and omitted settings values explicit. This unlocks a few
more settings in the settings UI
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Includes the start of how we can get rid of most of the `.unimplemented`
"Edit in JSON" buttons in the settings UI. For now only Theme selection
is implemented, follow ups will add more settings
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes#40334
This reverts the change made in #39983, and includes a replacement
migration that will transform formatter settings values consisting of
only `code_action` format steps into the previously deprecated
`code_actions_on_format` in an attempt to restore the behavior to what
it was before the migration that deprecated `code_actions_on_format`.
This PR will result in a modified order in the `code_actions_on_format`
setting if it existed, however the decision was made to explicitly
ignore this for now, as this PR is primarily targeting users who have
already had the deprecation migration run, and no longer have the
`code_actions_on_format` key
Release Notes:
- Fixed an issue with a settings migration that deprecated the
`code_actions_on_format` setting. The `code_actions_on_format` setting
has been un-deprecated, and affected users will have the bad migration
rolled back with an updated migration
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: HactarCE <6060305+HactarCE@users.noreply.github.com>
Closes#40270
Release Notes:
- Fixed an issue with the settings migration to flatten `code_actions`
format steps where comments would cause enabled code actions to be
omitted from the migrated settings. If you were effected, restoring the
settings file backup and allowing the migration to re-run will result in
a valid settings file
- Fixed an issue where automated settings and keymap file updates would
occasionally assume 4-space indentation
Follow up for: #39983 and
https://github.com/zed-industries/zed/pull/40040#issuecomment-3393902691
Previously it was possible to have formatting done using prettier or
language server using `"formatter": "auto"` and specify code actions to
apply on format using the `"code_actions_on_format"` setting. However,
post #39983 this is no longer possible due to the removal of the
`"code_actions_on_format"` setting. To rectify this regression, this PR
makes it so that the `"auto"` and `"language_server"` strings that were
previously only allowed as top level values on the `"formatter"` key,
are now allowed as format steps like so:
```json
{
"formatter": ["auto", "language_server"]
}
```
Therefore to replicate the previous behavior using `"auto"` and
`"code_actions_on_format"` you can use the following configuration:
```json
{
"formatter": [{"code_action": ...}, "auto"]
}
```
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Annotated our `default.json` with `$schema` to get diagnostics, then
fixed the non-language not installed warnings.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Release Notes:
- settings: Deprecated `code_actions_on_format` in favor of specifying
code actions to run on format inline in the `formatter` array.
Previously, you would configure code actions to run on format like this:
```json
{
"code_actions_on_format": {
"source.organizeImports": true,
"source.fixAll.eslint": true
}
}
```
This has been migrated to the new format:
```json
{
"formatter": [
{
"code_action": "source.organizeImports"
},
{
"code_action": "source.fixAll.eslint"
}
]
}
```
This change will be automatically migrated for you. If you had an
existing `formatter` setting, the code actions are prepended to your
formatter array (matching the existing behavior). This migration applies
to both global settings and language-specific settings
Closes #ISSUE
From notes:
```markdown
- [x] Clicking on the disclsoure icon button in the root-level tree view item should steal focus and move it to the root item (not the icon button)
- [x] [@ben] Allow left/right arrow keys to expand/collapse root tree view items in the nav
- [x] With this, make enter/space work the same as clicking (activate page, don't expand root items, focus moves to the content and leaves nav — becomes consistent with mouse interaction)
- [x] Smart cmd-shift-e: toggling focus should take you to the selected item
- [x] [@ben] pageup + pagedown in nav -> jump between root items
- [x] [@ben] home + end buttons should work
- in nav:
- home always goes to first section header
- end always goes to last _visible_ item (does not expand)
```
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Release Notes:
- settings: Removed support for having format steps in both the
`format_on_save` and `formatter` settings for languages.
`format_on_save` is now restricted to the values of `"on"` and `"off"`,
and all format steps should be set under the `formatter` key. If you
were using `format_on_save` but not `formatter` this will be migrated
for you, otherwise it will require a manual migration.
---------
Co-authored-by: Smit <smit@zed.dev>
Closes #ISSUE
Adds the ability to create settings and keymap migrations by mutating
`serde_json::Value`s instead of using tree-sitter queries. This
(hopefully) will make complicated migrations far simpler to implement.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Smit <heysmitbarmase@gmail.com>
Co-authored-by: Smit <smit@zed.dev>
Closes #ISSUE
Release Notes:
- settings: Changed code action format in `formatter` and
`format_on_save` settings.
**Previous format:**
```
{
"code_actions": {
"source.organizeImports": true,
"source.fixAll": true
}
}
```
**New format:**
```
[
{"code_action": "source.organizeImports"},
{"code_action": "source.fixAll"}
]
```
After #39246, code actions run sequentially in order. The structure now
reflects this and aligns with other formatter options (e.g., language
servers).
Both the `formatter` and `format_on_save` settings will be
auto-migrated.
Closes#39112
Release Notes:
- Fixed an issue when using code actions on format where specifying
multiple code actions in the same code actions block that resolved to
code actions from different language servers could result in conflicting
edits being applied and mangled buffer text.
Closes #ISSUE
Improves the efficiency of our interactions with the Zed language
server. Previously, on startup and after every workspace configuration
changed notification, we would send >1MB of JSON Schemas to the JSON
LSP. The only reason this had to happen was due to the case where an
extension was installed that would result in a change to the JSON schema
for settings (i.e. added language, theme, etc).
This PR changes the behavior to use the URI LSP extensions of
`vscode-json-language-server` in order to send the server URI's that it
can then use to fetch the schemas as needed (i.e. the settings schema is
only generated and sent when `settings.json` is opened. This brings the
JSON we send to on startup and after every workspace configuration
changed notification down to a couple of KB.
Additionally, using another LSP extension request we can notify the
server when a schema has changed using the URI as a key, so we no longer
have to send a workspace configuration changed notification, and the
schema contents will only be re-requested and regenerated if the schema
is in use.
Release Notes:
- Improved the efficiency of communication with the builtin JSON LSP.
JSON Schemas are no longer sent to the JSON language server in their
full form. If you wish to view a builtin JSON schema in the language
server info tab of the language server logs (`dev: open language server
logs`), you must now use the `editor: open url` action with your cursor
over the URL that is sent to the server.
- Made it so that Zed urls (`zed://...`) are resolved locally when
opened within the editor instead of being resolved through the OS. Users
who could not previously open `zed://*` URLs in the editor can now do so
by pasting the link into a buffer and using the `editor: open url`
action (please open an issue if this is the case for you!).
---------
Co-authored-by: Michael <michael@zed.dev>
Closes #ISSUE
Updates the settings editor to collect all known settings files from the
settings store, in order to show them in the UI. Additionally adds a
fake worktree instantiation in the settings UI example binary in order
to have more than one file available when testing.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Move the data table component created for the Keymap Editor to the UI
crate. Additionally includes simplifications to the scrollbar component
in UI necessary for the table component to support scrollbar
configurations, and a fix for an issue with the table component where
when used with the `.row` API instead of `uniform_list` the rows would
render on top of each other.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Adds the ability to our JSON updating code to update arrays within other
objects. Previously updating of arrays was limited to just top level
arrays (i.e. `keymap.json`) however this PR makes it so nested arrays
are supported as well using `#{index}` syntax as a key.
This PR also fixes an issue with the array updating code that meant that
updating empty json values `""` or an empty `keymap.json` file in the
case of the Keymap Editor would fail instead of creating a new array.
Release Notes:
- Fixed an issue where keybindings would fail to save in the Keymap
Editor if the `keymap.json` file was completely empty
Closes #ISSUE
Adds handling for Enums with fields (i.e. not `enum Foo { Yes, No }`) in
Settings UI. Accomplished by creating default values for each element
with fields (in the derive macro), and rendering a toggle button group
with a button for each variant where switching the active variant sets
the value in the settings JSON to the default for the new active
variant.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Conrad <conrad@zed.dev>
Closes #ISSUE
Fixed an issue where the first frame of the `Editing` page in onboarding
would have a slight delay before rendering the first time it was
navigated to. This was caused by listing the OS fonts on the main
thread, blocking rendering. This PR fixes the issue by adding a new
method to the font family cache to prefill the cache on a background
thread.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Mikayla Maki <mikayla.c.maki@gmail.com>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Anthony <anthony@zed.dev>
Closes #ISSUE
Centralizes the references to the `ZED_STATELESS` env var into a single
location in a new crate named `zed_env_vars`
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Adds a test that checks that all settings have default values in
`default.json`. Currently only tests that settings supported by
SettingsUi have defaults, as more settings are added to the settings
editor they will be added to the test as well.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Improves the derive macro for `SettingsUi` so that titles generated from
struct and field names are shown in title case, and toggle button groups
use title case for rendering, while using lower case/snake case in JSON
Release Notes:
- N/A *or* Added/Fixed/Improved ...
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 ...
Closes #ISSUE
Adds a first draft of a way for "Dynamic" settings items to be added,
where Dynamic means settings where multiple sets of options are possible
(i.e. discriminated union, rust enum, etc). The implementation is very
similar to that of `Group`, except that instead of rendering all of it's
descendants, it contains a function to determine _which_ descendant to
render, whether that be a single item or a nested group of items.
Currently this is done in a type-unsafe way with indices, a future
improvement could be to make the API more type safe, and easier to
manually implement correctly.
An example of a "Dynamic" setting is `theme`, where it can either be a
string of the desired theme name, or an object with `mode: "light" |
"dark" | "system"` as well as theme names for `light` and `dark`. In the
system implemented by this PR, this would become a dynamic settings UI
item, where option `0` is a single item, the theme name selector, and
option `1` is a group, containing items for the `mode`, and
`light`/`dark` options.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Adds a dependency on `serde_path_to_error` to the workspace allowing us
to include the path to the setting that failed to parse on settings
parse failure.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Enables LSP log tracing in both remote collab and remote ssh
environments.
Server logs and server RPC traces can now be viewed remotely, and the
LSP button is now shown in such projects too.
Closes https://github.com/zed-industries/zed/issues/28557
Co-Authored-By: Kirill <kirill@zed.dev>
Co-Authored-By: Lukas <lukas@zed.dev>
Release Notes:
- Enabled LSP log tracing in both remote collab and remote ssh
environments
---------
Co-authored-by: Kirill Bulatov <kirill@zed.dev>
Co-authored-by: Lukas Wirth <lukas@zed.dev>
Closes #ISSUE
Creates a function named `normalized_ctx_eq` that compares
`gpui::KeybindContextPredicate`'s while taking into account the
associativity of the binary operators. This function is now used to
compare context predicates in the keymap editor, greatly improving the
number of cases caught by our overloading and conflict detection
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Adds system GPU collection to crash reporting. Currently this is Linux
only.
The system GPUs are determined by reading the `/sys/class/drm` directory
structure, rather than using the exisiting `gpui::Window::gpu_specs()`
method in order to gather more information, and so that the GPU context
is not dependent on Vulkan context initialization (i.e. we still get GPU
info when Zed fails to start because Vulkan failed to initialize).
Unfortunately, the `blade` APIs do not support querying which GPU _will_
be used, so we do not know which GPU was attempted to be used when
Vulkan context initialization fails, however, when Vulkan initialization
succeeds, we send a message to the crash handler containing the result
of `gpui::Window::gpu_specs()` to include the "Active" gpu in any crash
report that may occur
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Adds `merge_message` field to the `UpdateRepository` proto message so
that suggested merge messages are displayed in remote projects.
Release Notes:
- git: Fixed an issue where suggested merge commit messages would not
appear for remote projects
Closes #ISSUE
Release Notes:
- Keymap Editor: Fixed an issue where leaving the arguments field empty
would result in an error even if arguments were optional
Closes #ISSUE
Release Notes:
- Keymap Editor: Added a button in the top left to allow opening the
keymap JSON file. Right clicking the button provides shortcuts to
opening the default Zed and Vim keymaps as well.
Closes #ISSUE
Adds a bit of text in the keybind editing modal when there are existing
keystrokes with the same key, with the ability for the user to click the
text and have the keymap editor search be updated to show only bindings
with those keystrokes
Release Notes:
- Keymap Editor: Added a warning to the keybind editing modal when
existing bindings have the same keystrokes. Clicking the warning will
close the modal and show bindings with the entered keystrokes in the
keymap editor. This behavior was previously possible with the
`keymap_editor::ShowMatchingKeybinds` action in the Keymap Editor, and
is now present in the keybind editing modal as well.
Closes #ISSUE
Allows tabbing through everything in all three pages. Until #35075 is
merged it is not possible to actually "click" tab focused buttons with
the keyboard.
Additionally adds an action `onboarding::Finish` and displays the
keybind. The action corresponds to both the "Skip all" and "Start
Building" buttons, with the keybind displayed similar to how it is for
the page nav buttons
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: MrSubidubi <finn@zed.dev>
Going back to having system be mutually exclusive with light/dark to
simplify the system. We instead just show both light and dark when
system is selected
Release Notes:
- N/A
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Closes #ISSUE
Serializes the onboarding page to the database to ensure that if Zed is
closed during onboarding, re-opening Zed restores the onboarding state
and the most recently active page (Basics, Editing, etc) restored. Also
has the nice side effect of making dev a bit nicer as it removes the
need to re-open onboarding and navigate to the correct page on each
build.
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
The behavior of the theme selector is documented above the function,
copied here for reference:
```rust
/// separates theme "mode" ("dark" | "light" | "system") into two separate states
/// - appearance = "dark" | "light"
/// - "system" true/false
/// when system selected:
/// - toggling between light and dark does not change theme.mode, just which variant will be changed
/// when system not selected:
/// - toggling between light and dark does change theme.mode
/// selecting a theme preview will always change theme.["light" | "dark"] to the selected theme,
///
/// this allows for selecting a dark and light theme option regardless of whether the mode is set to system or not
/// it does not support setting theme to a static value
```
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Following #35310, . This PR makes it so the lychee link check is ran
before building the docs on the md files to catch basic errors, and then
after building on the html output to catch generation errors, including
regressions like the one #35380 fixes.
Release Notes:
- N/A
Closes #ISSUE
Adds basic frontmatter support to `.md` files in docs. The only
supported keys currently are `description` which becomes a `<meta
name="description" contents="...">` tag, and `title` which becomes a
normal `title` tag, with the title contents prefixed with the subject of
the file.
An example of the syntax can be found in `git.md`, as well as below
```md
---
title: Some more detailed title for this page
description: A page-specific description
---
# Editor
```
The above will be transformed into (with non-relevant tags removed)
```html
<head>
<title>Editor | Some more detailed title for this page</title>
<meta name="description" contents="A page-specific description">
</head>
<body>
<h1>Editor</h1>
</body>
```
If no front-matter is provided, or If one or both keys aren't provided,
the title and description will be set based on the `default-title` and
`default-description` keys in `book.toml` respectively.
## Implementation details
Unfortunately, `mdbook` does not support post-processing like it does
pre-processing, and only supports defining one description to put in the
meta tag per book rather than per file. So in order to apply
post-processing (necessary to modify the html head tags) the global book
description is set to a marker value `#description#` and the html
renderer is replaced with a sub-command of `docs_preprocessor` that
wraps the builtin `html` renderer and applies post-processing to the
`html` files, replacing the marker value and the `<title>(.*)</title>`
with the contents of the front-matter if there is one.
## Known limitations
The front-matter parsing is extremely simple, which avoids needing to
take on an additional dependency, or implement full yaml parsing.
* Double quotes and multi-line values are not supported, i.e. Keys and
values must be entirely on the same line, with no double quotes around
the value.
The following will not work:
```md
---
title: Some
Multi-line
Title
---
```
* The front-matter must be at the top of the file, with only white-space
preceding it
* The contents of the title and description will not be html-escaped.
They should be simple ascii text with no unicode or emoji characters
Release Notes:
- N/A *or* Added/Fixed/Improved ...
---------
Co-authored-by: Katie Greer <katie@zed.dev>
Closes #ISSUE
Additional cleanup and testing for the keystroke input including
- Focused testing of the "previous modifiers" logic in search mode
- Not merging unmodified keystrokes into previous modifier only bindings
(extension of #35208)
- Fixing a bug where input would overflow in search mode when entering
only modifiers
- Additional testing logic to ensure keystrokes updated events are
always emitted correctly
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Introduces a mechanism whereby keystrokes that have a post-fix which
matches the prefix of the stop recording binding can still be entered.
The solution is to introduce a (as of right now) 300ms timeout before
the close keystroke state is wiped.
Previously, with the default stop recording binding `esc esc esc`,
searching or entering a binding ending in esc was not possible without
using the mouse. `e.g.` entering keystroke `ctrl-g esc` and then
attempting to hit `esc` three times would stop recording on the
penultimate `esc` press and the final `esc` would not be intercepted.
Now with the timeout, it is possible to enter `ctrl-g esc`, pause for a
moment, then hit `esc esc esc` and end the recording with the keystroke
input state being `ctrl-g esc`.
I arrived at 300ms for this delay as it was long enough that I didn't
run into it very often when trying to escape, but short enough that a
natural pause will almost always work as expected.
Release Notes:
- Keymap Editor: Added a short timeout to the stop recording keybind
handling in the keystroke input, so that it is now possible using the
default bindings as an example (custom bindings should work as well) to
search for/enter a binding ending with `escape` (with no modifier),
pause for a moment, then hit `escape escape escape` to stop recording
and search for/enter a keystroke ending with `escape`.
Closes #ISSUE
Separate out the keystroke input into it's own component and add a bunch
of tests for it's core keystroke+modifier event handling logic
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Closes #ISSUE
Fixes a bug that was cherry picked onto stable and preview branches
introduced in #35208 whereby modifier keys would show up and not be
removable when editing a keybind
Release Notes:
- (preview only) Keymap Editor: Fixed an issue introduced in v0.197.2
whereby modifier keys would show up and not be removable while recording
keystrokes in the keybind edit modal
Closes #ISSUE
Fixed various issues and improved UX around the keystroke input
primarily when used for keystroke search.
Release Notes:
- Keymap Editor: FIxed an issue where the modifiers used to activate
keystroke search would appear in the keystroke search
- Keymap Editor: Made it possible to search for repeat modifiers, such
as a binding with `cmd-shift cmd`
- Keymap Editor: Made keystroke search matches match based on ordered
(not necessarily contiguous) runs. For example, searching for `cmd
shift-j` will match `cmd-k cmd-shift-j alt-q` and `cmd-i g shift-j` but
not `alt-k shift-j` or `cmd-k alt-j`
- Keymap Editor: Fixed the clear keystrokes binding (`delete` by
default) not working in the keystroke input
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 #ISSUE
Simplifies the API to no longer have a variant that returns indices. The
downside is that a few places that used to call
`bindings_for_action_with_indices` now compare `Box<dyn Action>` instead
of indices, however the result is the removal of wrapper code and index
handling that is largely unnecessary
Release Notes:
- N/A *or* Added/Fixed/Improved ...
Co-authored-by: Conrad <conrad@zed.dev>
Ben Kunkle
