@@ -1024,25 +1024,15 @@ fn split_selection_on_newline(cx: &mut Context) {
1026fn search_impl(doc: &mut Document, view: &mut View, contents: &str, regex: &Regex, extend: bool) {
1026fn 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(..);
1028 let selection = doc.selection(view.id);
1028 let selection = doc.selection(view.id);
1029 let start = {
1029 let start = {
1030+ // Get the right side of the block cursor.
1030 let range = selection.primary();
1031 let range = selection.primary();
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
1039− if range.anchor <= range.head {
1032+ if range.anchor < range.head {
1040− text.char_to_byte(range.head)
1033+ range.head
1041 } else {
1034 } else {
1042− text.char_to_byte(graphemes::next_grapheme_boundary(
1035+ graphemes::next_grapheme_boundary(text, range.head)