This PR implements a UI for the side-by-side diff, using blocks to align
the two sides and adding a coherent `SplitEditorElement`.
Release Notes:
- N/A
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: Anthony Eid <hello@anthonyeid.me>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Previously, when project search results first appeared, vim would
incorrectly switch to Visual mode. This happened because vim settings
(including `collapse_matches`) weren't synced to an editor until it
received focus. Since the results editor wasn't focused when the first
match was selected, the selection wasn't collapsed, causing vim to
interpret it as a visual selection.
Now vim settings are synced immediately when vim activates on an editor,
ensuring `collapse_matches` is set before any selections are made.
Closes#43878
Release Notes:
- Fixed vim mode incorrectly switching to Visual mode on first project
search
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
Closes#46516
The previous fix only worked for non-nested folds, whereas this one also
considers nested folds properly. Also makes this more straightforward to
read.
Release Notes:
- Fixed an issue where relative line numbering would break with nested
folds.
Fixes an issue where `editor::AddSelectionAbove` and
`editor::AddSelectionBelow`, when set with `skip_soft_wrap: true` ,
would lose track of the original cursor column when passing through
short lines, as `editor::Editor.add_selection` was not using the oldest
selection's column range when adding a new selection.
These changes update the `editor::Editor.add_selection` method so as to
keep track of the olde selection's column range for each group, as well
as extracting `find_next_columnar_selection_by_display_row` and
`find_next_columnar_selection_by_buffer_row` helper methods to clarify
the two navigation strategies.
Closes#46842
Release Notes:
- Fixed `editor::AddSelectionAbove` and `editor::AddSelectionBelow` when
skipping over soft-wrapped lines to preserve the original cursor column
when adding selections through lines shorter than the starting position
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>
Happy New Years! This PR is a second take at
https://github.com/zed-industries/zed/pull/38127 (cc @ConradIrwin)
This PR is significantly less complicated than the last attempt: while
we still keep our data on the `NavigationHistory` object, we no longer
tightly integrate it with the existing back/forward "browser history."
Instead, we keep our own stack of `(origin, target)` pairs (in a struct
to make it easy to extend with e.g., tag names in the future).
The PR is split into two separable commits. Most of the implementation
is in the second commit, which:
- Defines the stack data structure
- Implements `pane::GoToOlderTag` and `pane::GoToNewerTag` in terms of
the stack
- Hooks into `navigate_to_hover_links` to push tag stack entries
This last bit is the most fiddly. The core challenge is that we need to
keep track of the `origin` location and calculate the `target` location
across three codepaths that might involve creating a new editor and/or
splitting the pane. One thing in particular I found difficult was that
an editor's `nav_history` (an `ItemNavHistory`) seems to be populated
asynchronously. Instead of relying on it, I decided in this code to make
my own `ItemNavHistory`. I briefly tried to refactor the code in
question, but it seemed like it would significantly increase the scope
of the change.
I prefer this all-in-one tracking centered around
`navigate_to_hover_links ` to the `start/finish` approach taken in
https://github.com/zed-industries/zed/commit/aebd394fb60641a2dd32b1f1b76a7c79ec4aa2ea
because I find it easier to convince myself that the right data is being
populated at the right times. Of course, let me know if you think
there's a better solution.
Closes#14206
Release Notes:
- ??? I don't know what to write here! Suggestions welcome
Release Notes:
- Opening bundled files, keymap, and local release notes now opens in
remote windows instead of opening a new local zed window
- Opening the settings files, keymap files, task files, debug files and
logs will now open within wsl windows instead of opening a new local zed
window
Doesn't support editing or deleting comments yet, but inputs work:
<img width="797" height="881" alt="Screenshot 2026-01-14 at 11 51 36 AM"
src="https://github.com/user-attachments/assets/746e085b-a919-475a-b804-ee0377e40a0b"
/>
<img width="698" height="178" alt="Screenshot 2026-01-14 at 11 47 51 AM"
src="https://github.com/user-attachments/assets/3edac0e8-62e5-4af5-a324-df2bd293f3ca"
/>
<img width="695" height="695" alt="Screenshot 2026-01-14 at 11 47 58 AM"
src="https://github.com/user-attachments/assets/64795ffd-62b4-48ea-a46c-7724221095d7"
/>
### Features implemented:
- **Local comment storage**: Comments are stored per-hunk in the Editor,
with chronological ordering
- **Expandable comments section**: Shows "N Comments" header that can
expand/collapse
- **Inline editing**: Click edit to transform a comment row into an
editable text field with confirm/cancel buttons
- **Delete functionality**: Remove individual comments
- **Send Review to Agent**: Toolbar button with badge showing comment
count, batch-submits all comments across all files/hunks to the Agent
panel
- **User avatars**: Shows the current user's avatar (from their Zed
account) next to comments, falls back to Person icon when not logged in
- **Visual tests**: Added tests for one comment, multiple comments
expanded, and comments collapsed
Note that this is behind a feature flag, so no release notes yet.
Release Notes:
- N/A
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
Co-authored-by: David Baldwin <baldwindavid@gmail.com>
Release Notes:
- When copying and pasting from a multibuffer view (e.g. into the agent
panel), the line numbers from the selection corresponded to the line
numbers in the multibuffer view (incorrect), instead of the actual line
numbers from the file itself.
- I also handled the case in which the selection spans multiple excerpts
(different files in the multibuffer) by just returning None for that
case, but maybe it should instead be split into two selections?
Left is before (bugged, should be lines 8:16, instead it is 38:46),
right is after (fixed).
<div style="display:flex; gap:12px;">
<img
src="https://github.com/user-attachments/assets/b1bfce1d-8b6a-41c0-ac7e-51f7bd7b284e"
width="48%" />
<img
src="https://github.com/user-attachments/assets/2a4c33a0-a969-4a3e-9aa5-d2c2fefba3b2"
width="48%" />
</div>
Release Notes:
- Added two actions `move_to_start_of_larger_syntax_node` and
`move_to_end_of_larger_syntax_node` that move cursors to the start or
end of the parent tree-sitter node
Following up on my PR #41321, this PR only adds the actions that are
used to enable code navigation across syntax nodes, without binding them
to any keys (such as tab) by default. Both actions use the tree-sitter
syntax tree to find parent nodes of the nodes the cursors are currently
in. `move_to_start_of_larger_syntax_node` will then move each cursor to
the first position of the parent nodes while
`move_to_end_of_larger_syntax_node` to a position right after the parent
nodes.
Related issues and discussions: #22349, #14803, #42828, #13736.
This PR doesn't achieve "tab out" functionality in the exact sense as is
requested in these issues as it does not bind the actions to the tab
key. I hope this PR can start some discussion on what the best way
forward for these issues is. In the meantime, users can configure keys
to use these actions as they see fit to emulate "tab out" behavior. For
example,
```
"context": "Editor && vim_mode == insert && !in_snippet && !showing_completions",
"bindings": {
"tab": "editor::MoveToEndOfLargerSyntaxNode",
"shift-tab": "editor::Tab"
}
```
This will enable tab to skip past code structures like brackets when the
cursor is not in a snippet or the autocomplete menu is not open. At the
same time, shift tab will act as a backup tab.
This PR adds the ability to open local terminals when working in remote
projects. When working in a remote (often actually remoting into a local
container) I always need to run separate terminals outside Zed so I can
run local build tools, scripts, agents, etc. for the related project.
I'd like to be able to run all of these in the same Zed window and this
adds that ability via one-off local terminals.
## Changes
Adds an optional `local` parameter to terminal commands. When set to
`true`, creates a local shell on your machine instead of connecting to
the remote.
### Implementation
- Added `force_local` parameter to terminal creation logic
- Created `create_local_terminal()` method that bypasses remote client
- Updated terminal actions (`NewTerminal`, `NewCenterTerminal`) to
accept optional `local: bool` field (defaults to `false`)
### Usage
**Via keybinding:**
```json
{
"bindings": {
"cmd-t": "workspace::NewCenterTerminal",
"cmd-T": ["workspace::NewCenterTerminal", { "local": true }]
}
},
{
"context": "Terminal",
"bindings": {
"cmd-n": "workspace::NewTerminal",
"cmd-N": ["workspace::NewTerminal", { "local": true }],
},
},
```
**Behavior:**
- Default terminal commands continue to work as before (remote in remote
projects, local in local projects)
- The `local` parameter is optional and defaults to `false`
Release Notes:
- Added support for opening local terminals in remote projects via
`local` parameter on terminal commands.
When using the `editor::actions::CopyAndTrim` action with a multi-line
selection in vim's Visual Line mode, pasting would crash Zed.
The bug occurred because trimming splits a selection into per-line
ranges, creating multiple `editor::ClipboardSelection` entries. However,
when `is_entire_line` was true (Visual Line mode), no newline separators
were added between these entries in the clipboard text. The paste code
then assumed separators existed and read past the end of the text.
The fix ensures newline separators are always added between trimmed line
ranges, regardless of whether the original selection was in line mode.
Closes#46616
Release Notes:
- Fixed a crash when pasting after using `editor: copy and trim` in
vim's Visual Line mode
Adds a very simple diff review button behind a feature flag, which
appears in the gutter of people who have the flag (currently just me;
it's not even enabled for staff, since it doesn't do anything yet).
Mostly this PR just adds the feature flag, the button, and tests.
Release Notes:
- N/A
Stumbled across this upon a PR review - `unfold_ranges` takes a slice of
Ranges and already clones the ranges itself, so we do not need to clone
the selections prior to passing these.
Release Notes:
- N/A
Closes#40110
Changes:
- `DeleteToPreviousSubwordStart` now deletes `\n` separately from
preceding subwords and whitespace.
- `DeleteToNextSubwordEnd` now deletes `\n` and any following whitespace
separately from subsequent subwords.
- Added an `ignore_newlines` flag to both actions to optionally retain
the old behavior.
These modifications align the subword commands with their word
counterparts and with other popular editors like VSCode and Sublime.
Related to: https://github.com/zed-industries/zed/pull/16848
Release Notes:
- Improved `DeleteToPreviousSubwordStart` and `DeleteToNextSubwordEnd`
interactions around newlines. You can opt-in into the previous behavior
by adding `{"ignore_newlines": true}` to either action's binds in your
keymap.
---
This is my first contribution to Zed! If anything should be done
differently, please let me know. Happy to learn :)
## Summary
Fixes#33633 - folds corrupting after external file modifications.
The existing fold persistence stored raw byte offsets, which become
stale when files are modified externally (git operations, other editors,
sync tools). This caused folds to capture wrong content on restore -
users reported "wrong lines getting folded" with systematic offsets.
**Solution: Content fingerprinting**
- Store 32-byte content samples at fold boundaries
- On restore, validate fingerprints match; if not, search buffer for new
positions
- Handles edge cases: short folds (< 32 bytes), duplicate content,
boundary positioning
**Bonus fix: Ungraceful exit survival**
- Entity IDs change between sessions, but workspace cleanup's CASCADE
DELETE was wiping folds before new editors could save
- Now migrates folds to new entity_id immediately after restore
## Test plan
- [x] Unit test for fingerprint storage/retrieval
(`test_save_and_get_editor_folds_with_fingerprints`)
- [x] Manual test: fold sections, add content at file start externally,
reopen → folds restore at correct positions
- [x] Manual test: fold sections, Ctrl+C, reopen → folds survive
- [x] Existing fold tests pass (`cargo test -p editor`)
## Release Notes
- N/A
---------
Co-authored-by: Hector <hector@cyberneticwilderness.com>
Also improves the commit view to use the same status-based buffer header
visual overrides as the project diff as a driveby.
Fixes https://github.com/zed-industries/zed/issues/45735
Release Notes:
- git: Binary files are no longer shown in garbled form when viewing an
old commit.
Breadcrumb visual reorchestration which makes a couple of key changes:
- Breadcrumbs are now displayed in file headers for multibuffer views.
Singleton buffers are unchanged.
- Multibuffer views now have collapse/expand all buttons available in
the toolbar
- Search in multibuffer views now takes up less space, by occupying the
primary toolbar location erstwhile taken up by breadcrumbs
<img width="1721" height="823" alt="Screenshot 2025-12-22 at 4 15 41 PM"
src="https://github.com/user-attachments/assets/38e924f7-fe9e-4c83-84fb-2eee98137f43"
/>
<img width="1722" height="762" alt="Screenshot 2025-12-22 at 4 15 51 PM"
src="https://github.com/user-attachments/assets/ccc98ca3-75ce-4aca-bceb-890817b0f04d"
/>
Release Notes:
- Moved breadcrumbs to file headers in multibuffer views
- Added collapse/expand all options for multibuffer views
- Improved use of space for multibuffer search by taking the place of
the former breadcrumb toolbar location
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
When adding selections above/below with `skip_soft_wrap: true`, use
buffer column positions instead of pixel positions. This ensures
selections are placed at the same column offset in the buffer rather
than at the same visual position, which was incorrect for soft-wrapped
lines.
For example, selecting "how" in a wrapped line:
````
1. Very long line to
show [how] a wrapped
line would look
2. Very long line to
show how a wrapped
line would look
````
Now correctly adds a selection at the same buffer column in the next
line:
````
1. Very long line to
show [how] a wrapped
line would look
2. Very long line to
show [how] a wrapped
line would look
````
Closes#42137
Release Notes:
- Improved `editor: add selection above` and `editor: add selection
below` to select at the same text column when skipping soft-wrapped
lines, instead of the same visual position
Closes#45046
The root of the issue is anchor resolution. When we apply adjacent
edits, they get merged into a single edit. In the scenario described in
the issue, this is what happens:
1. We create an anchor at the end of each selection (bias::right) on the
snapshot before the edits.
2. We collect the edits and apply them to the buffer.
3. Since the edits are adjacent (>=), the buffer merges them into a
single edit.
4. As a result, we apply one edit to the text buffer, creating a single
visible fragment with length = 3.
5. The buffer ends up with fragments like: [F(len = 3, visible = true),
F(len = 1, visible = false), ...]
6. After the edits, we resolve the previously created anchors to produce
zero-width selections (cursors).
7. All anchors resolve into deleted fragments, so their resolved offset
equals the cumulative visible offset, which is 3.
8. We now have 3 cursors with identical coordinates (0;3).
9. These cursors get merged into a single cursor.
I tried several approaches, but they either felt wrong or didn’t work.
In particular, I tried adjusting anchor resolution using the delta
stored in handle_input, but this doesn’t help because selections are
merged immediately after anchor resolution.
The only workable solution I found is to avoid anchors entirely for the
adjacent-edit case. Instead, we can compute the final cursor positions
directly from the edits and create the selections based on that
information.
Release Notes:
- Fixed an issue where adjacent selection insert would merge cursors
---------
Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
Co-authored-by: Lukas Wirth <me@lukaswirth.dev>
This mimics VSCode's `files.readonlyExclude` setting, to allow setting
specific path matches as readonly locations like lockfiles and generated
sources etc.
Also renders a lock icon to the right side of the path names for
readonly files now.
This does a couple more things for completion sake:
- Tabs of readonly buffers now render a file lock icon
- Multibuffer buffer headers now render a file lock icon if the excerpts
buffer is readonly
- ReadWrite multibuffers now no longer allow edits to read only buffers
contained within
Release Notes:
- Added `read_only_files` setting to allow specifying glob patterns of
files that should not be editable by default
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
Closes#45496
Should help #43460
And probably also #44503
The minimap usually renders about 10x more lines of code and shaped text
than the editor. With expensive fonts such as Google Sans Code, this can
cause noticeable lag, since we attempt to synthesize 300+ lines of code
using a heavy font. Because minimap text is rendered at around 2px and
is essentially illegible, it doesn’t make sense to use the custom buffer
font.
Release Notes:
- Improved minimap performance when using custom fonts
---------
Signed-off-by: Marco Mihai Condrache <52580954+marcocondrache@users.noreply.github.com>
Closes#45960
Release Notes:
- Made the `extension` key context case-insensitive. This e.g. enables
the `markdown: Open Preview` action to also handle files where the
extension is capitalised as MD (case-sensitive file system).
This PR reworks the (still feature-gated) side-by-side diff view to use
a different approach to representing the multibuffers on the left- and
right-hand sides.
Previously, these two multibuffers used identical sets of buffers and
excerpts, and were made to behave differently by adding a new knob to
the multibuffer controlling how diffs are displayed. Specifically, the
left-hand side multibuffer would filter out the added range of each hunk
from the excerpts using a new `FilteredInsertedHunk` diff transform, and
the right-hand side would simply not show the deleted sides of expanded
hunks. This approach has some problems:
- Line numbers, and actions that navigate by line number, behaved
incorrectly for the left-hand side.
- Syntax highlighting and other features that use the buffer syntax tree
also behaved incorrectly for the left-hand side.
In this PR, we've switched to using independent buffers to build the
left-hand side. These buffers are constructed using the base texts for
the corresponding diffs, and their lifecycle is managed by `BufferDiff`.
The red "deleted" regions on the left-hand side are represented by
`BufferContent` diff transforms, not `DeletedHunk` transforms. This
means each excerpt on the left represents a contiguous slice of a single
buffer, which fixes the above issues by construction.
The tradeoff with this new approach is that we now have to manually
synchronize excerpt ranges from the right side to the left, which we do
using `BufferDiffSnapshot::row_to_base_text_row`.
Release Notes:
- N/A
---------
Co-authored-by: cameron <cameron.studdstreet@gmail.com>
Co-authored-by: HactarCE <6060305+HactarCE@users.noreply.github.com>
Co-authored-by: Miguel Raz Guzmán Macedo <miguel@zed.dev>
Co-authored-by: Anthony <anthony@zed.dev>
Co-authored-by: Cameron <cameron@zed.dev>
Follow-up to https://github.com/zed-industries/zed/pull/45164 which
caused the active line number to always be `0` instead of the actual
current line number. No release notes since its only on nightly
Release Notes:
- N/A
Closes#42586
This includes a rewrite of `calculate_relative_line_numbers()`. Now it's
linear-time with respect to the number of rows displayed, instead of
linear time with respect to the number of rows displayed _plus_ the
distance to the base row.
Release Notes:
- Improved performance when using relative line numbers in large files
- Fixed relative line numbers not appearing in sticky headers
Closes#5089
Release notes:
- Markdown lists now continue automatically when you press Enter
(unordered, ordered, and task lists). This can be configured with
`extend_list_on_newline` (default: true).
- You can now indent list markers with Tab to quickly create nested
lists. This can be configured with `indent_list_on_tab` (default: true).
---------
Co-authored-by: Claude <noreply@anthropic.com>
Co-authored-by: Smit Barmase <heysmitbarmase@gmail.com>
Closes#26424
Supersedes #35328
Originally, `git::blame` uses its own `ParsedCommitMessage` as the
source for the commit information, including the PR section. This
changes unifies this with `git::repository` and `git_ui::git_panel` by
moving this and some other commit-related structs to `git::commit`
instead, and making both `git_ui::blame_ui` and `git_ui::git_panel` pull
their information from these structs.
Release notes :
- (Let's Git Together) Fixed the commit tooltip in the git panel not
showing information like avatars.
---------
Co-authored-by: Cole Miller <cole@zed.dev>
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
This PR introduces support for Next Edit Suggestions while doing away
with calling legacy endpoints. In the process we've also removed support
for cycling completions, as NES will give us a single prediction, for
the most part.
Closes#30124
Release Notes:
- Zed now supports Copilot's [Next Edit
Suggestions](https://code.visualstudio.com/blogs/2025/02/12/next-edit-suggestions).
Closes #ISSUE
Problem:
- The status bar’s pending keystroke indicator (shown next to --NORMAL--
in Vim mode) didn’t clear when focus moved to another context, e.g.
hitting g in the editor then clicking the Git panel. The keymap state
correctly canceled the prefix, but observers that render the indicator
never received a “pending input changed” notification, so the UI kept
showing stale prefixes until a new keystroke occurred.
Fix:
- The change introduces a `pending_input_changed_queued` flag and a new
helper `notify_pending_input_if_needed` which will flushes the queued
notification as soon as we have an App context. The
`pending_input_changed` now resets the flag after notifying subscribers.
Before:
https://github.com/user-attachments/assets/7bec4c34-acbf-42bd-b0d1-88df5ff099aa
After:
https://github.com/user-attachments/assets/2264dc93-3405-4d63-ad8f-50ada6733ae7
Release Notes:
- Fixed: pending keybinding prefixes on the status bar now clear
immediately when focus moves to another panel or UI context.
---------
Co-authored-by: Nathan Sobo <nathan@zed.dev>
Co-authored-by: Conrad Irwin <conrad.irwin@gmail.com>
Some refactoring I ran into while working on automatic Markdown list
continuation on newline.
This PR:
- Moves `comment_delimiter` and `documentation_delimiter` computation
outside of newline method.
- Adds `NewlineFormatting`, which holds info about how newlines affect
indentation and other formatting we need.
- Moves newline-specific methods into the new `NewlineFormatting`
struct.
Release Notes:
- N/A
Fixes an issue where we would update the imports after a file rename in
TypeScript, but those changes wouldn't surface anywhere until those
buffers were manually opened
(https://github.com/zed-industries/zed/issues/35930#issuecomment-3366852945).
In https://github.com/zed-industries/zed/pull/36681 we already added
support for opening a multibuffer with edits, but vtsls has a different
flow for renames.
Release Notes:
- Files with updated imports now open in a multibuffer when renaming or
moving TypeScript or JavaScript files
Hi,
This PR fixes nothing. I just miss the option to open recent projects
quickly upon opening Zed, so I made this. Hope I can see it soon in
Preview channel.
If there is any suggestion, just comment. I will take it seriously.
Thank you!
|ui|before|after|
|-|-|-|
|empty pane|<img width="1571" height="941" alt="Screenshot 2025-12-03 at
12 39 25"
src="https://github.com/user-attachments/assets/753cbbc5-ddca-4143-aed8-0832ca59b8e7"
/>|<img width="1604" height="952" alt="Screenshot 2025-12-03 at 12 34
03"
src="https://github.com/user-attachments/assets/2f591d48-ef86-4886-a220-0f78a0bcad92"
/>|
|new window|<img width="1571" height="941" alt="Screenshot 2025-12-03 at
12 39 21"
src="https://github.com/user-attachments/assets/a3a1b110-a278-4f8b-980e-75f5bc96b609"
/>|<img width="1604" height="952" alt="Screenshot 2025-12-04 at 10 43
17"
src="https://github.com/user-attachments/assets/74a00d91-50da-41a2-8fc2-24511d548063"
/>|
---
Release Notes:
- Added a new value to the `restore_on_startup` setting called
`launchpad`. This value makes Zed open with a variant of the welcome
screen ("the launchpad") upon startup. Additionally, this same page
variant is now also what is displayed if you close all tabs in an
existing window that doesn't contain any folders open. The launchpad
page shows you up to 5 recent projects, making it easy to open something
you were working recently.
---------
Co-authored-by: Danilo Leal <daniloleal09@gmail.com>
- **Fix editor::OpenUrl on zed links**
- **Fix cmd-clicking links too**
Closes#44293Closes#43833
Release Notes:
- The `editor::OpenUrl` action now works for links to https://zed.dev
- Clicking on a link to a Zed channel or channel-note within the editor
no-longer redirects you via the web.
---------
Co-authored-by: Zed Zippy <234243425+zed-zippy[bot]@users.noreply.github.com>
In a previous Pull Request, a new field was added to `editor::Editor`,
namely `cursor_offset_on_selection`, in order to control whether the
cursor representing the head of a selection should be positioned in the
last selected character, as we have on Vim mode, or after, like we have
when Vim mode is disabled.
This field would then be set by the `vim` crate, depending on the
current vim mode. However, it was noted that
`vim_mode_setting::VimModeSetting` already exsits and allows other
crates to determine whether Vim mode is enabled or not. Since we're
already checking `!range.is_empty()` in
`editor::element::SelectionLayout::new` we can then rely on simply
determining whether Vim mode is enabled to decide whether tho shift the
cursor one position to the left when making a selection.
As such, this commit removes the `cursor_offset_on_selection` field, as
well as any related methods in favor of a new `Editor.vim_mode_enabled`
method, which can be used to achieve the same behavior.
Relates to #42837
Release Notes:
- N/A
Closes#4644
Release Notes:
- Adds `MousePressureEvent`, an event that is sent anytime the touchpad
pressure changes, into `gpui`. MacOS only.
- Triggers go-to-defintion on force clicks in the editor.
This is my first contribution, let me know if I've missed something
here.
---------
Co-authored-by: Anthony Eid <anthony@zed.dev>
Co-authored-by: Antonio Scandurra <me@as-cii.com>
We called out to `request_on_type_formatting` only in handle_input
function, but newlines are actually handled by editor::Newline action.
Closes#12383
Release Notes:
- Added support for on-type formatting with newlines.
Vim visual mode and Helix selection mode both require the cursor to be
on the last character of the selection. Until now, this was implemented
by offsetting the cursor one character to the left whenever a block
cursor is used. (Since the visual modes use a block cursor.)
However, this oversees the problem that **some users might want to use
the block cursor without being in visual mode**. Meaning that the cursor
is offset by one character to the left even though Vim/Helix mode isn't
even activated.
Since the Vim mode implementation is separate from the `editor` crate
the solution is not as straightforward as just checking the current vim
mode. Therefore this PR introduces a new `Editor` struct field called
`cursor_offset_on_selection`. This field replaces the previous check
condition and is set to `true` whenever the Vim mode is changed to a
visual mode, and `false` otherwise.
Closes#36677 and #20121
Release Notes:
- Fixes block and hollow cursor being offset when selecting text
---------
Co-authored-by: dino <dinojoaocosta@gmail.com>
