editor: Fix block cursor offset when selecting text by lennartkloock · Pull Request #42837 · zed-industries/zed

lennartkloock · 2025-11-16T15:33:05Z

Closes #36677 and #20121

Problem

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.)

zed/crates/editor/src/element.rs

Line 153 in 1683052

if (cursor_shape == CursorShape::Block || cursor_shape == CursorShape::Hollow)

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.

Solution

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 condition above and is set to true whenever the Vim mode is changed to a visual mode, and false otherwise.

If there is a better solution without having to add a new Editor field, let me know.

Release Notes:

Fixes block and hollow cursor being offset when selecting text

dinocosta · 2025-11-25T17:41:52Z

Hey @lennartkloock , thank you for opening this Pull Request 👋

I'm wondering if I'm doing something wrong or testing the wrong cgghanges, but seems like these changes don't actually fix the reproduction steps shared in #36677 . Here's a screen recording of me comparing both the current Zed Nightly with your changes ▼

CleanShot.2025-11-25.at.12.37.06.mp4

In both cases I still see the issue with using shift-cmd-right not visually selecting all of the elements in the line. Are these changes trying to solve a different issue?

Also, not sure if it helps but we also have the editor::vim_flavor function that you can access from the editor, not sure if it helps but a solution where we don't need to add new fields would be preferred, as this also seems like we might just need to fix editor::SelectToEndOfLine and editor::SelectToBeginningOfLine when vim mode is enabled 🙂

lennartkloock · 2025-11-25T18:39:14Z

Hey @lennartkloock , thank you for opening this Pull Request 👋

I'm wondering if I'm doing something wrong or testing the wrong cgghanges, but seems like these changes don't actually fix the reproduction steps shared in #36677 . Here's a screen recording of me comparing both the current Zed Nightly with your changes ▼
CleanShot.2025-11-25.at.12.37.06.mp4

In both cases I still see the issue with using shift-cmd-right not visually selecting all of the elements in the line. Are these changes trying to solve a different issue?

Also, not sure if it helps but we also have the editor::vim_flavor function that you can access from the editor, not sure if it helps but a solution where we don't need to add new fields would be preferred, as this also seems like we might just need to fix editor::SelectToEndOfLine and editor::SelectToBeginningOfLine when vim mode is enabled 🙂

The issue doesn't happen in Vim mode. To reproduce the problem you have to disable Vim mode and enable the block or hollow cursor. Thanks for pointing me to that function, I will look if it helps in this case.

Edit: I don't know if I'm missing something but I think both editor::SelectToEndOfLine and editor::SelectToBeginningOfLine are completely fine and work like expected, right?

Edit: nvm I just saw the other issue #38104 but seems like it's unrelated because it only happens in Vim mode

lennartkloock · 2025-11-25T20:11:57Z

Unfortunately, the editor::vim_flavor function doesn't help here because we have to figure out not only if the editor is in Vim mode but also if it is in visual mode.

That said, what we could do is use editor::vim_flavor to check if it is in Vim mode and then use the cursor_shape field to determine if it is in visual mode but in my opinion that field shouldn't be used like that because it results in bugs like this one.

dinocosta · 2025-11-26T18:07:57Z

The issue doesn't happen in Vim mode. To reproduce the problem you have to disable Vim mode and enable the block or hollow cursor.

Would you be able to share reproduction steps? I'm still having a hard time reproducing the issue that this Pull Request is attempting to fix 🙂

dinocosta · 2025-12-03T10:18:20Z

Has there been any progress? I’m really in need of this fix.

@aurexav If possible, can you share a small reproduction of the issue? Wanted to confirm that these changes actually fixed the issue but seems I was unable to reproduce the actual issue to check if it fixed it.

aurexav · 2025-12-03T10:26:14Z

Has there been any progress? I’m really in need of this fix.

@aurexav If possible, can you share a small reproduction of the issue? Wanted to confirm that these changes actually fixed the issue but seems I was unable to reproduce the actual issue to check if it fixed it.

Use block cursor
Open a file
Put cursor at the beginning of a line
Press shift + end

Zed

Zed Underline

VSCode

And you can continue press right. And the cursor won't move to next line. The selection is completely wrong.

The memory level selection is correct but the visual is completely wrong.

lennartkloock · 2025-12-03T15:34:02Z

Thanks for sharing the reproduction steps, I didn't have time yet. You can also see this when selecting text using your mouse.

dinocosta · 2025-12-05T10:30:01Z

@aurexav Thank you for sharing those steps! When you state "1. Use block cursor", do yo mean the following settings?

{
  "cursor_shape": "block",
}

If so, I just tested these changes, comparing how it behaves against the latest stable release and it appears the behavior for shift-end is still the same ▼

CleanShot.2025-12-05.at.10.28.57.mp4

The behavior of editor::SelectToEndOfLine does appear to be broken but it seems that the changes in this Pull Request don't actually fix it? Let me know if I'm missing something, thanks!

And you can continue press right. And the cursor won't move to next line. The selection is completely wrong.

If you have vim mode enabled, I believe this is meant to replicate vim's behavior, where if you're at the end of the line, pressing l will not continue the selection on the next line.

lennartkloock · 2025-12-07T09:08:01Z

@aurexav Thank you for sharing those steps! When you state "1. Use block cursor", do yo mean the following settings?
{
  "cursor_shape": "block",
}
If so, I just tested these changes, comparing how it behaves against the latest stable release and it appears the behavior for shift-end is still the same ▼
CleanShot.2025-12-05.at.10.28.57.mp4

The behavior of editor::SelectToEndOfLine does appear to be broken but it seems that the changes in this Pull Request don't actually fix it? Let me know if I'm missing something, thanks!

And you can continue press right. And the cursor won't move to next line. The selection is completely wrong.

If you have vim mode enabled, I believe this is meant to replicate vim's behavior, where if you're at the end of the line, pressing l will not continue the selection on the next line.

I don't know if there is a misunderstanding here but it seems like you are still in Vim mode in your video. The issue that is fixed here only appears if you're NOT in Vim mode. Please disable Vim mode for the reproduction steps to work. (set "vim_mode": false in your settings file)

aurexav · 2025-12-08T07:55:40Z

@aurexav Thank you for sharing those steps! When you state "1. Use block cursor", do yo mean the following settings?
{
  "cursor_shape": "block",
}

Yes.

If you have vim mode enabled, I believe this is meant to replicate vim's behavior, where if you're at the end of the line, pressing l will not continue the selection on the next line.

I'm a VIM hater. I never use that mode.

lennartkloock · 2025-12-09T11:15:03Z

Here is a video I recorded demonstrating the issue. I hope that helps to further clarify it.

Settings are:

{
  "vim_mode": false,
  "cursor_shape": "block",
}

Screencast.From.2025-12-09.12-12-03.mp4

dinocosta · 2025-12-11T21:09:09Z

Thank you for sharing @lennartkloock , was probably confusing what the real issue was but I've been able to reproduce it too! Will take a look at these changes shortly, likely during next week's Quality Week 🙂

Since we're already updating the vim's editor in that function, we can avoid an extre call to `self.update_editor`.

…Settings (#44889) 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

aurexav · 2025-12-16T01:01:27Z

Will this be included in Thursday's preview version?

…2837) 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 zed-industries#36677 and zed-industries#20121 Release Notes: - Fixes block and hollow cursor being offset when selecting text --------- Co-authored-by: dino <dinojoaocosta@gmail.com>

…Settings (zed-industries#44889) 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 zed-industries#42837 Release Notes: - N/A

dinocosta · 2025-12-16T10:16:29Z

Will this be included in Thursday's preview version?

I believe so. We're planning on making new releases a little bit sooner this week, seeing as next week a lot of folks are going to be out of office 🙂

cla-bot bot added the cla-signed The user has signed the Contributor License Agreement label Nov 16, 2025

lennartkloock changed the title ~~editor: Fix block cursor offset on select~~ editor: Fix block cursor offset when selecting text Nov 16, 2025

lennartkloock mentioned this pull request Nov 16, 2025

Block cursor position is inconsistent with highlighting #36677

Closed

lennartkloock force-pushed the fix-cursor-offset branch from 82080f4 to 3e6799c Compare November 16, 2025 19:20

SomeoneToIgnore assigned dinocosta Nov 24, 2025

lennartkloock added 2 commits November 25, 2025 21:14

editor: Fix block cursor offset on select

ec045b9

editor: Fix test

84ed3ad

lennartkloock force-pushed the fix-cursor-offset branch from 3e6799c to 84ed3ad Compare November 25, 2025 20:14

zelenenka added this to Quality Week – December 2025 Nov 27, 2025

github-project-automation bot moved this to Community PRs in Quality Week – December 2025 Nov 27, 2025

This comment was marked as spam.

Sign in to view

refactor: move editor update to sync_vim_settings

364d0f7

Since we're already updating the vim's editor in that function, we can avoid an extre call to `self.update_editor`.

dinocosta merged commit 5fe7fd9 into zed-industries:main Dec 15, 2025
23 checks passed

github-project-automation bot moved this from Community PRs to Done in Quality Week – December 2025 Dec 15, 2025

dinocosta mentioned this pull request Dec 15, 2025

editor: Refactor cursor_offset_on_selection field in favor of VimModeSettings #44889

Merged

jrobsonchase mentioned this pull request Jan 10, 2026

helix: Always offset cursor on selection #46311

Open

mikalsande mentioned this pull request Jan 12, 2026

Select to end of line does not work properly with vim normal mode #38104

Closed

Uh oh!

Conversation

lennartkloock commented Nov 16, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Problem

Solution

Uh oh!

dinocosta commented Nov 25, 2025

Uh oh!

lennartkloock commented Nov 25, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lennartkloock commented Nov 25, 2025

Uh oh!

dinocosta commented Nov 26, 2025

Uh oh!

This comment was marked as spam.

dinocosta commented Dec 3, 2025

Uh oh!

aurexav commented Dec 3, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lennartkloock commented Dec 3, 2025

Uh oh!

dinocosta commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

lennartkloock commented Dec 7, 2025

Uh oh!

aurexav commented Dec 8, 2025

Uh oh!

lennartkloock commented Dec 9, 2025

Uh oh!

dinocosta commented Dec 11, 2025

Uh oh!

Uh oh!

aurexav commented Dec 16, 2025

Uh oh!

dinocosta commented Dec 16, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

3 participants

lennartkloock commented Nov 16, 2025 •

edited

Loading

lennartkloock commented Nov 25, 2025 •

edited

Loading

aurexav commented Dec 3, 2025 •

edited

Loading

dinocosta commented Dec 5, 2025 •

edited

Loading