editor: Add SelectInsideDelimiters and SelectAroundDelimiters actions

[subeax]

Summary

Adds two new editor actions:

• editor::SelectInsideDelimiters: selects the content inside the nearest enclosing delimiters. Works for (), [], {}, and string literals ("", '', ` `).
• editor::SelectAroundDelimiters: same as above, but the selection includes the surrounding delimiters themselves.

This addresses the request in #50042

Why not select_larger_syntax_node?

SelectLargerSyntaxNode walks up the AST one level at a time. It's an incremental, history-aware operation: press repeatedly to expand outward by syntax tree level. The number of presses needed to reach a specific delimiter pair depends on the language's AST shape and is unpredictable: sometimes one press, sometimes three, sometimes overshoot.

SelectInsideDelimiters is delimiter-based and stateless: one invocation jumps directly to the nearest enclosing pair, regardless of AST nodes. It's the equivalent of Vim's vi(, vi{, vi" text objects, available without requiring Vim mode. The two actions solve different problems.

Implementation

Both actions use MultiBufferSnapshot::innermost_enclosing_bracket_ranges, which already handles nesting, multi-buffer excerpts, and language-specific bracket definitions, including languages where quotes are declared as bracket pairs (Rust, Python, JavaScript, JSON, etc.).

For string-like content where the language does not register quotes as brackets (notably Markdown inline content), SelectInsideDelimiters additionally falls back to a syntax_ancestor check for tree-sitter node kinds string_content and inline. This is the same set of node kinds already used in select_larger_syntax_node.

Multi-cursor support comes from move_offsets_with.

Tests

Two new tests in editor_tests.rs covering:

• Basic delimiter selection (parens, brackets, braces)
• Innermost detection with nested pairs
• String content selection (TypeScript)
• Selection expansion when starting from an existing selection
• No-op when cursor is not inside any delimiter

Notes

No default keybindings are provided. Users can bind via their keymap. Can add defaults if reviewers prefer.

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 #50042

Release Notes:

• Added editor: select inside delimiters and editor: select around delimiters actions for selecting content within the nearest enclosing brackets, braces, parentheses, or quotes. Repeating the action expands the selection to the next enclosing pair.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @subeax on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[cla-bot]

We require contributors to sign our Contributor License Agreement, and we don't have @subeax on file. You can sign our CLA at https://zed.dev/cla. Once you've signed, post a comment here that says '@cla-bot check'.

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[cla-bot]

The cla-bot has been summoned, and re-checked this pull request!

[dinocosta]

Won't be able to get to this day, and I'm not even sure if I'll be the one reviewing these changes, but thought it would be worth mentioning that there's maybe already some functionality to support this specific use case in the vim crate. For example, one can use vi ([v]isual [i]nside) followed by the specific delimiter in order to select the whole text inside the specific delimiter.

So if we do decide to add this, it might make sense to move some of that logic from the vim crate to the editor crate and have the vim implementation leverage it instead of re-implementing it on the editor side, if possible 🙂

[subeax]

That makes sense. I took a look at the Vim implementation, and it currently lives as part of Vim's text-object machinery rather than as a generic editor primitive.

In particular, crates/vim/src/object.rs implements surrounding_markers() plus object-specific selection behavior (escape handling, whitespace rules for around, multiline behavior, nearest/innermost fallback), so it is not a drop-in editor abstraction today.

For this PR I kept the editor action scoped to a simpler generic delimiter selection behavior. If we want the semantics to converge, I agree the right follow-up would be to extract a shared lower-level delimiter-finding helper and have Vim build on top of it where appropriate, rather than duplicating the matching logic in two places.

[dinocosta]

Hey @subeax ! 👋

Thank you for the reply to my feedback. I had another look at these changes and seems like a good implementation.

However, I noticed that the quote-related fallback present in Editor::select_delimiters_impl seems to only be supported when using SelectAroundDelimiters and not when using SelectInsideDelimiters, which you can see in the recording below.

CleanShot.2026-06-15.at.13.32.16.mp4

This doesn't seem to make much sense to me so I was wondering if this was on purpose or if I can go ahead and remove that !include_brackets check 🙂

[subeax]

Hi @dinocosta

Thanks! Removed include_brackets check and added some Markdown tests as well.

[dinocosta]

Thanks @subeax ! 🙌

Pushed a smaller commit simplifying some of the tests. I'll merge this after tomorrow's release 🙂

[dinocosta]

I'm actually going to merge this now . Was planning on holding off and fully replacing the editor: select inside enclosing bracket action introduced by #59005 by these two actions but though that action was already available in Preview and wanted to avoid having a period where all three actions (editor: select inside enclosing bracket, editor: select inside delimiters and editor: select around delimiters) would be available in the command palette.

Luckily, I noticed that editor: select inside enclosing bracket hasn't made it into Preview yet, so I'm merging these now and opening the clean up right after! 🫡