Make search work a little nicer when there are already selections.

Specifically, if you have text like "aaaaaaaaa" and you search
for "a", the new behavior will actually progress through all of the
"a"s, whereas the previous behavior would be stuck on a single one.

1 files changed, 19 insertions, 1 deletions

diff --git a/helix-term/src/commands.rs b/helix-term/src/commands.rs
index d1092f20..5964e354 100644
--- a/helix-term/src/commands.rs
+++ b/helix-term/src/commands.rs
@@ -1041,7 +1041,25 @@ fn split_selection_on_newline(cx: &mut Context) {
 fn search_impl(doc: &mut Document, view: &mut View, contents: &str, regex: &Regex, extend: bool) {
     let text = doc.text();
     let selection = doc.selection(view.id);
-    let start = text.char_to_byte(selection.cursor(text.slice(..)));
+    let start = {
+        let range = selection.primary();
+
+        // This is a little bit weird.  Due to 1-width cursor semantics, we
+        // would typically want the search to always begin at the visual left-side
+        // of the head.  However, when there's already a selection from e.g. a
+        // previous search result, we don't want to include any of that selection
+        // in the subsequent search.  The code below makes a compromise between the
+        // two behaviors that hopefully behaves the way most people expect most of
+        // the time.
+        if range.anchor <= range.head {
+            text.char_to_byte(range.head)
+        } else {
+            text.char_to_byte(graphemes::next_grapheme_boundary(
+                text.slice(..),
+                range.head,
+            ))
+        }
+    };
 
     // use find_at to find the next match after the cursor, loop around the end
     // Careful, `Regex` uses `bytes` as offsets, not character indices!