byte index + 1 will run into the issue that this may advance into part of a multibyte UTF-8 character, producing nonsense and a panic downstream.

Do you think the min(buffer_len) can help here?
If not would you kindly suggest alternative way to approach the wrong current selection range issue?

Instead of (selection_anchor, self.insertion_point() you could use (selection_anchor, self.line_buffer.grapheme_right_index()).
For the else branch i am not sure. You could change the grapheme_right_index method to allow passing a 'cursor position' and then call it with selection_anchor. Along the lines of:

    pub fn grapheme_right_index_from_pos(&self, pos: usize) -> usize {
        self.lines[pos..]
            .grapheme_indices(true)
            .nth(1)
            .map(|(i, _)| pos + i)
            .unwrap_or_else(|| self.lines.len())
    }

Yup, something along those lines sounds right. We advance the cursor always a full grapheme (e.g. so you don't get stuck between an accent and a vowel or the components of an emoji if they are composite and rendered together)

Here it is also worth checking if changing the semantics of the selection for Vi visual mode doesn't introduce a regression for our selection stuff in the emacs mode.

Goot catch! Thank you Johannes for the helpful example. I've made the change as you suggest, tested it and added unittests for the new grapheme_right_index_from_pos method.

It looks we've agreed on all points of this PR. Please help review and feel free to throw qs / edit / merge.

Not sure if the mode change should occur for the Change/Incomplete combination already? At least in normal mode we should remain there. Different story in Visual mode, so maybe that is what you are trying to achieve.

We just may want to defend against it becoming an issue in normal mode.

Same for the delete part.

Agree the mode change depends on current mode. Fixed this in the 5th commit of this PR (if you'd like to squash it works together with the 1st commit).

Looks good, at first I was wondering about the special delete versions you had in the previous versoins but they are unreachable in visual mode due to all of them starting with d... Oh do we have to handle an x here?

I believe x should be handled, to be consistent with most Vim editors (including the classic vi): Under visual mode user is able to select a range and delete with either x or d.