@@ -1024,25 +1024,15 @@ fn split_selection_on_newline(cx: &mut Context) {
10241024}
10251025
10261026fn search_impl(doc: &mut Document, view: &mut View, contents: &str, regex: &Regex, extend: bool) {
1027− let text = doc.text();
1027+ let text = doc.text().slice(..);
10281028 let selection = doc.selection(view.id);
10291029 let start = {
1030+ // Get the right side of the block cursor.
10301031 let range = selection.primary();
1031−
1032− // This is a little bit weird. Due to 1-width cursor semantics, we
1033− // would typically want the search to always begin at the visual left-side
1034− // of the head. However, when there's already a selection from e.g. a
1035− // previous search result, we don't want to include any of that selection
1036− // in the subsequent search. The code below makes a compromise between the
1037− // two behaviors that hopefully behaves the way most people expect most of
1038− // the time.
1039− if range.anchor <= range.head {
1040− text.char_to_byte(range.head)
1032+ if range.anchor < range.head {
1033+ range.head
10411034 } else {
1042− text.char_to_byte(graphemes::next_grapheme_boundary(
1043− text.slice(..),
1044− range.head,
1045− ))
1035+ graphemes::next_grapheme_boundary(text, range.head)
10461036 }
10471037 };
10481038