From 01247acf0cd06fcb3ba3b033e215b9b13b632816 Mon Sep 17 00:00:00 2001
From: Nathan Vegdahl
Date: Mon, 26 Jul 2021 08:50:26 -0700
Subject: Start searches at the right side of the block cursor.

---
 helix-term/src/commands.rs | 20 +++++---------------
 1 file changed, 5 insertions(+), 15 deletions(-)

diff --git a/helix-term/src/commands.rs b/helix-term/src/commands.rs
index 86ede415..89042acb 100644
--- a/helix-term/src/commands.rs
+++ b/helix-term/src/commands.rs
@@ -1024,25 +1024,15 @@ 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 text = doc.text().slice(..);
     let selection = doc.selection(view.id);
     let start = {
+        // Get the right side of the block cursor.
         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)
+        if range.anchor < range.head {
+            range.head
         } else {
-            text.char_to_byte(graphemes::next_grapheme_boundary(
-                text.slice(..),
-                range.head,
-            ))
+            graphemes::next_grapheme_boundary(text, range.head)
         }
     };
 
-- 
cgit v1.2.3-70-g09d2