Hi, I’m new to Kakoune and I find some things unexpected/inconsistent. Not sure if that is bug or desired behavior.
- 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
- paste line after single char selection actually pastes on next line
- empty buffer,
i1line<ret><esc>kxyghp
, selection is on 1 before paste
- 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
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.