Some confusing behavior

Hi, I’m new to Kakoune and I find some things unexpected/inconsistent. Not sure if that is bug or desired behavior.

  1. Resulting selection is different after r
    • empty buffer, r1: replaces _ with char 1, selection is on 1
    • empty buffer, iline<ret><esc>r1: replaces _ with char 1, selection is on 1 and _ after that
    • empty buffer, iline<ret>c<esc>r1: replaces _ with char 1, selection is on 1 only
  2. paste line after single char selection actually pastes on next line
    • empty buffer, i1line<ret><esc>kxyghp, selection is on 1 before paste
  3. undo paste moves selection
    • empty buffer, i1line<ret><esc>kxyghpu, after paste selection is on 1, after undo it is on the end of line

What I refer to as _ is I guess End-Of-Line and some kind of End-Of-File? Because even if buffer is empty documentation says that Kakoune always has some selection.

1 Like
  1. Not sure but probably something to do with the fact that the final EOL character can’t be removed.
  2. Is because you pasted something with an EOL in it. Like in vim this inserts the copied text as a new line below the cursor.
  3. Undoing (or anything that alters text in the current buffer) can do weird things with selections because Kakoune doesn’t save every selection change, additionally an insert/removal can invalidate the current selection. A developer could speak more to the exact implementation but as I understand it Kakoune guesses a selection that makes sense for the text that was changed. For example if you undo a deletion it will select the deleted text. Your paste added text to line 2 so it assumes your cursor was on line 2 where the insertion began. In reality the interaction between paste and EOL characters means that your cursor was on the line above but Kakoune doesn’t know this.
1 Like

As for the 2. case, using x selects the whole line including it’s EOL character. So to select whole line without the EOL character, do xH.

Points 2 and 3 have been explained, but does anyone have a way to understand the behavior in point 1? I’ve been trying to deduce the general rule but so far it’s not very predictable.

In 1a and 1c, you’re deleting the last newline of the buffer, so another newline gets appended to ensure the buffer ends in a newline. It seems reasonable to me that Kakoune adds the newline after the replacement is done: it does the edit, it checks to see if the buffer still ends with a newline, then an extra newline is appended.

In 1b, I’m not sure what’s going on, but I know that Kakoune represents a buffer as a list of lines. Possibly there’s an optimisation that means a line isn’t “real” until it’s non-empty, and the quirk demonstrated by 1b is a symptom of the line being “made real” before the editing is performed.

1 Like

Thanks. I agree the behavior should be as in 1a and 1c, and this is logical.

But perhaps 1b qualifies as a bug, since it does not follow this pattern? Is this worth raising an issue on github, or pinging the maintainer here? (I’m not sure what protocol is for this project.)

GitHub is absolutely the place for bug reports.

It would definitely help if somebody could dig into the code and figure out exactly why this happens, and it would help even more if somebody could devise a simple way to fix it. I’m not sure if anyone is particularly eager to dive into this problem, so I’m not sure what the prospects of fixing it are, but if it’s on GitHub hopefully somebody will get around to it eventually.

The GitHub issue is here.