editor: Fix columnar selection alignment on rows with multi-byte chars

[Dnreikronos]

Self-Review Checklist:

• I've reviewed my own diff for quality, security, and reliability
• Unsafe blocks (if any) have justifying comments
• The content is consistent with the UI/UX checklist
• Tests cover the new/changed behavior
• Performance impact has been considered and is acceptable

Closes #56748

Summary

Block / column selection (Shift+Ctrl+drag on Linux, Shift+Cmd+drag on macOS) anchored its rectangle on a single byte column applied to every row in the dragged range. On a row whose text contained a multi-byte character before that column (for example ã), the same byte offset mapped to a different visual x, so the per-row cursor drifted off the column.

select_columns now anchors the rectangle in x pixels via x_for_display_point and resolves each row's byte column with display_column_for_x — the same pair of helpers already used by vertical cursor motion and Vim VisualBlock.

Before / After

Before — cursor on the ã row drifts one column to the left:

After — rectangle stays visually aligned across rows:

Test plan

• cargo test -p editor test_columnar_selection_with_multibyte_chars (new regression test covers the buggy case past the ã byte boundary, plus a control case where old and new logic agree).
• Manual: Shift+Ctrl+drag down a five-line buffer where row 3 contains ã — selection rectangle stays aligned (see screenshots).
• Manual: Shift+Alt+drag (FromSelection branch) over the same buffer — same result.
• Manual: drag past EOL on the ã row — each row extends to its own EOL with no panic.

Release Notes:

• Fixed misalignment of column selection on rows that contain multi-byte characters

[tomhoule]

I am wondering if this is the expected behaviour for users who use variable width fonts (also applies to mixed language text where some of it may be variable width). I know a few.

[Dnreikronos]

Yeah, as I remember, this is intentional. it's basically the same thing Zed already does in a couple other spots:

• vertical cursor movement (Up/Down) keeps the cursor at the same visual x across rows of different widths, via SelectionGoal::HorizontalPosition + display_column_for_x in editor/src/movement.rs.
• Vim's Ctrl-V VisualBlock also builds its rectangle from a pixel range, resolving each row with closest_index_for_x in vim/src/visual.rs.

a columnar selection is kinda just a visual rectangle, so anchoring in x is what keeps the left/right edges actually vertical on screen for variable-width fonts and mixed-width text like CJK. the old byte-column anchoring drew a ragged selection in exactly those cases, which is the same root cause behind #56748. so imo this just brings mouse columnar selection in line with the two cases above instead of leaving it as the odd one out.

idk, if you'd rather have a column-count model for variable-width fonts i'm open to it, but that'd diverge from how vertical motion and VisualBlock already behave. lgtm as is though, lmk what you think.

[tomhoule]

You're right! Reviewing the implementation now.

[tomhoule]

I noticed the behaviour was not completely expected. When the cursor was past the end of any of the lines in the selected block, the selected area would clip to the last column of the shortest line, which does not line up with the expectation for a rectangular selection, so I pushed some tweaks.

Here's current main:

Screen.Recording.2026-06-12.at.11.05.45.mov

This branch before:

Screen.Recording.2026-06-12.at.11.08.02.mov

This branch after:

Screen.Recording.2026-06-12.at.11.10.31.mov

Notice there's still some odd behaviour when the cursor is past the end of the text area.

[tomhoule]

Notice there's still some odd behaviour when the cursor is past the end of the text area.

I looked into fixing that, and it's not completely trivial, so best left to another PR.

This branch is already a big improvement, so let's merge it. Thank you for the contribution!