Closed danr closed 6 years ago
Yeah, I agree its a bad inconsistency.
It comes directly from the fact that we dont really append when we are on an eol. So there is at least two ways to fix that:
a
more regular, and just append including if we are on an eol, which means a
on an eol will jump to next line.a
, which is going to be a very specific behaviour.In the general case, a
selects whats inserted as a side effect of us moving the cursor to the next char when entering insert mode, while keeping the anchor where it was, so every newly inserted text (just before the cursor) is inserted inside the selection, making the selection grow.
Thanks, that helped me understand your intuition about append and the anchor. The following is what I expect append mode to work like (except that the cursor is at the wrong end of the selection):
def danr-append-mode %{
exec i
hook -group danr-append-mode buffer InsertChar .* %{
exec -no-hooks -itersel <esc>Zhdz<a-p><a-z><a-m>i
}
hook -group danr-append-mode buffer InsertEnd .* %{
rmhooks buffer danr-append-mode
}
}
map global normal a :danr-append-mode<ret>
So, if I get that correctly, you propose that a
does not insert in front of the cursor, but after the cursor, and just keeps the cursor on top of the last inserted char ?
Correct (I always found the append insertion point off-by-one.)
What do you think about it?
Reviving this, as I just was bit by this bug unexpectedly - if a line is empty or only contains whitespace, then a
won't extend the selection with the input.
Hello,
So, I have been thinking about that now that end of lines are even less special in Kakoune.
Lets say we let a jump to next line when the cursor is on eol, this would be consistent with the general behaviour of a but it still breaks in one case: when the cursor is on the last eol of the buffer. In that case, I see three possiblities:
The first one would be my favourite, but I am not convinced it would be much better than the status quo. Any opinions on that ?
I'm still using the "highlight-eol-to-window-end" branch, where it feels obvious and natural that selecting an EOL and hitting "a" would start typing at the beginning of the next line, even if it's the last line in the buffer.
If you hit "a" on the last eol in the buffer and start typing on the next line after it, would Kakoune automatically insert a new EOL after the cursor, so the new line is also terminated with an EOL, or would that need to be added manually?
Also, what about "A" on EOL? Would it jump back to before the EOL as it does now, or jump to before the following EOL? Whichever it does, "gl" will need to be consistent with it.
@Screwtapello a on last line eol would create a new line after it and start inserting there, A would not change behaviour, it would still start to insert before current line eol.
Just trying kakoune and this inconsistency wrt. the way append works has been bugging me as well.
In addition to the good reasons this is an issue given by @danr when he opened the issue, here is another reason this should be considered a bug:
When I hit ESC at the end of an append operation, I expect to see the cursor move back one position to the last appended character. This gives me confirmation that I exited insert mode (my eyes are on the appended text at this point, changing the status line doesn't help). This doesn't happen when appending at the end of a line.
For my $0.01, I think that appending when standing on the EOL should open a new line, for consistency, as described above (including adding a new line with a new LF if standing on the last EOL of a buffer).
Edit: I ended up mapping a
to li
which makes a
behaves consistently. The downside is that the appended text isn't selected - but since I dislike the fact that a
also selects the character you were at when you started appending, having nothing be selected is acceptable for me. YMMV.
For what my opinion is worth as a new user coming from vim, a
at the eol moving the cursor to the beginning of the next line is surprising and annoying. Changing the behavior to do this intentionally for the sake of "consistency" just seems kind of like favoring pedantry over a good user experience. (Being able to select the eol at all itself seems kind of strange and of questionable value, but I suppose that's a different topic.) If my cursor is at the end of the line, and I click "append", I expect to start appending to the line my cursor is on, not the next one.
Vim has ^
and $
to go to the beginning and end of the line. In Vim, if you hit $ab
you append b
to the end of the current line.
Kakoune has gh
and gl
to go to the beginning and end of the line. In Kakoune, if you hit glab
you append b
to the end of the current line.
In this respect, Kakoune and Vim work identically.
The difference is that Kakoune lets you select the newline character after the end of the line, where Vim hides newline characters and pretends they aren't part of the buffer. If the newline character is selected, you're not "at eol" in the sense of "where Vim's $
puts the cursor", you're past eol. No matter what a
does in this situation, it's going to be surprising and annoying for Vim users because Vim never lets you get into this situation to begin with.
As someone new to Kakoune, maybe I'm missing some use case here: what exactly is the utility of being able to select the eol?
For example, selecting the eol is handy to join lines: move the selection on this char and press d
.
Isn't that covered by <a-j>
(which works with the cursor in any position on the line)? Or even just jI<backspace>
?
At the end of lines append with
a
does not extend the selection.This behaviour feels confusing and inconsistent: I expect
a
to always select the inserted characters. (I find this the more defining ofa
than it enters insert mode on the character after point.)This inconsistency is frustrating in configs. It hit me today when trying
alexherbo2
's snazzy math prompt:This does not work at end of line because of this:
bc
only gets the last character.