From 1792dc6f935f581e7fed3842b1f01e2d5d3d7e05 Mon Sep 17 00:00:00 2001
From: Nathan Vegdahl
Date: Mon, 19 Jul 2021 18:29:26 -0700
Subject: 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.
---
 helix-term/src/commands.rs | 20 +++++++++++++++++++-
 1 file changed, 19 insertions(+), 1 deletion(-)

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!
-- 
cgit v1.2.3-70-g09d2