`split_selection` is producing a single letter selection if split sequence is at beggining of selection

[Isokaeder]

Summary

split_selection works not as I would expect if the split sequence is found at the beginning of the selection.

Reproduction Steps

I tried this:

1. hx
2. create file content abcccccccabccccccab
3. select entire word [abcccccccabccccccab] (areas denoted by [] are selected)
4. Split by subsequence "ab" (Sab<enter>)

I expected this to happen:
Only the "c"-sequences should be selected, like this: ab[ccccccc]ab[cccccc]ab

Instead, this happened:
Selection includes one single character at the very start [a]b[ccccccc]ab[cccccc]ab. However, note that the splitting worked as I would expect at the tail of the selection.

Helix log

n/a

Platform

macOS

Terminal Emulator

alacritty

Installation Method

brew

Helix Version

helix 25.07.1 (a05c151)

[Isokaeder]

Okay, I did some investigation and I think I found the right source of this behavior.

The function that splits the selection is called split_on_matches and I found this unit test with a comment that suggests that there is some reasoning behind keeping a zero-width range in the scenario I described:

helix/helix-core/src/selection.rs

Lines 1279 to 1317 in 2095586

	#[test]
	fn test_split_on_matches() {
	let text = Rope::from(" abcd efg wrs xyz 123 456");
	let selection = Selection::new(smallvec![Range::new(0, 9), Range::new(11, 20),], 0);
	let result = split_on_matches(
	text.slice(..),
	&selection,
	&rope::Regex::new(r"\s+").unwrap(),
	);
	assert_eq!(
	result.ranges(),
	&[
	// TODO: rather than this behavior, maybe we want it
	// to be based on which side is the anchor?
	//
	// We get a leading zero-width range when there's
	// a leading match because ranges are inclusive on
	// the left. Imagine, for example, if the entire
	// selection range were matched: you'd still want
	// at least one range to remain after the split.
	Range::new(0, 0),
	Range::new(1, 5),
	Range::new(6, 9),
	Range::new(11, 13),
	Range::new(16, 19),
	// In contrast to the comment above, there is no
	// _trailing_ zero-width range despite the trailing
	// match, because ranges are exclusive on the right.
	]
	);
	assert_eq!(
	result.fragments(text.slice(..)).collect::<Vec<_>>(),
	&["", "abcd", "efg", "rs", "xyz"]
	);
	}

When this selection is then committed via set_selection function there is a call to ensure_invariants which unfolds this zero-width range and makes it one character long - but only the one at the start not the one at the tail as I also observed:

helix/helix-core/src/selection.rs

Lines 656 to 665 in 2095586

	// Ensures the selection adheres to the following invariants:
	// 1. All ranges are grapheme aligned.
	// 2. All ranges are at least 1 character wide, unless at the
	// very end of the document.
	// 3. Ranges are non-overlapping.
	// 4. Ranges are sorted by their position in the text.
	pub fn ensure_invariants(self, text: RopeSlice) -> Self {
	self.transform(|r| r.min_width_1(text).grapheme_aligned(text))
	.normalize()
	}

---

So I think I understand the reasoning here. In the edge case that is described by the comment it makes sense to basically collapse the selection if the entire content of a selection is used to split itself, also to ensure that there is still a "cursor". But I think that edge-case is meaningfully different from just trying to shave off a start from a selection.

I think the split_on_matches function can be adjusted in such a way that it would keep the zero-width range only if the regex matches the entire remainder of the current selection and tosses it out if there is other survivors. If that's not desired because "shaving off" is not really the purpose of split_selection, then I propose a trim_selection command that is specifically for what I call "shaving off" at the edges of selections.