helix-mode: introduce HelixRange selection type (no wiring)

[kronberger-droid]

Summary

Introduces HelixRange, a anchor/head selection range type similar to helix-core, along with a Direction enum. The type has no callers yet and is gated behind #![allow(dead_code)] until future PRs.

Motivation

Part of #960, and follow-up to #1039.

Reedline already has selection state via Editor::selection_anchor plus the insertion point. That model fits vi's visual mode but doesn't carry two things helix needs:

• Direction: anchor and head are named, not just a min/max pair.
• Persistence: in helix, every motion produces a selection that survives until the next motion or operator clears it. selection_anchor exists only when the user has actively started a selection in vi.

Rather than retrofit selection_anchor to carry direction, this PR adds a helix-local type that encodes both properties.

Why direction matters

Behaviors that depend on this:

1. Block cursor placement (one grapheme inside the head edge)
2. Selection flip — swap the active end without losing the range
3. Extending motions know which edge to grow when the head moves

What's included

• HelixRange { anchor, head } with gap-indexing semantics (left-inclusive, right-exclusive, regardless of anchor/head ordering)
• Pure-integer methods on HelixRange
• Direction::{Forward, Backward} enum
• 32 unit tests

What's deliberately deferred

• Grapheme-aware methods: translate between byte positions and graphemes, and place the visible cursor on the correct side of the selection (future PR).
• Multi-range Selection: reedline is single line.

Adaptations from helix-core

helix-core	reedline	Why
RopeSlice	&str (future PRs)	reedline uses String, not Rope
char indices	byte offsets	reedline's established convention

Tests

cargo test --features helix --lib edit_mode::helix::range

All 32 tests pass.

The module is pub(super) and gated behind the helix feature flag, thus no behavior change possible.

[fdncred]

This is a pretty small changeset with many tests (thanks). It looks good to me but I'd like to get @schlich's input on it before we land it. Thanks!

[schlich]

I'll take a look either tonight or this weekend!

[fdncred]

@schlich Have you had time to review yet? Sorry to nag.

[schlich]

Hey @fdncred and @kronberger-droid et al! Sorry for the delay and silence, time has really been getting away from me. I'm just catching up, haven't looked at other threads/issues in here yet. And sorry for the wall of text paragraph , currently on mobile...

I was actually able to go over this one and was in the process of putting some feedback down and obtain my own understanding of the follow up issues that were referenced, of course some distractions came up and I wasn't able to submit a thoughtful review. From a high level the abstractions make sense although I was trying to piece together how they relate to the missing word boundary behavior we are tackling. I think that in the interest of moving things along its pretty safe to merge these objects so that we have them available, I'm not convinced how they fit in the big picture but it seems @kronberger-droid knows where we are going. Test logic seemed solid but again not the most thorough evaluation.

Will have much more time to work on reedline this week

[fdncred]

Thanks @schlich for getting back with us. Are you ready to land this @kronberger-droid ?

[kronberger-droid]

Yeah from my side its cleared. I am pretty confident that without this abstraction helix mode will be a mess. Next steps would be to continue the dicussion i started in the helix mode PR. since it will determine how to go forward.

[fdncred]

Thanks y'all. I'm trying to keep things moving so y'all aren't waiting on the nushell team.