-
-
Notifications
You must be signed in to change notification settings - Fork 2.5k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Unexpected behavior because of newline characters being selectable #2956
Comments
One issue with this is that for some commands it's necessary for For changing lines you could use a similar command as I do for selecting the line's content (minus leading and trailing whitespace): #2503 |
That makes sense - in that case vim/nvim probably are not a reasonable comparison due to their different editing model. For |
This is expected behaviour. We treat newlines like any other character which makes operations more consistent. We actually used to stop before EOL but this was changed to match kakoune's behaviour. Either:
|
There's some considerations around case 2 to add a C type binding that would change a single line. For now the easiest is |
Thanks for clearing that up. I'll close the issue. |
I think |
Man, i wish Sure, one can bind it, but if i wanted keybinds i would use vscode or some other non-modal editor instead. Unfortunately this is one of the primary reasons im sticking to nvim and i am sad about it since i really love how simple it is to configure helix. Hoping you will reconsider one day - i want to like this editor, i really do! |
Having read this thread after finding it due the exact same gripe... I now disagree. If the intention is to make behaviour consistent then I'd rather have the consistent behaviour because that affords less internal logic in Helix to deal with the edge cases created by inconsistent behaviour. Yes adding a keybinding can suck but I was in the camp of "I want this behaviour changed" 10 minutes ago but now I don't.
|
@tsujp Pretty much every program that works with texts gives newline representations (the many that there are) special treatment. Because they are an implementation detail separate from the dynamics of the text as it is intended to be interacted with. Having also come from the fragile and often laborious Neovim ecosystem what I am also finding frustrating about Helix is that it is very interested in consistency on the mechanical-editor action level, and not on the level of actual use. Which is to say that Helix demands you be very aware of it's select state and location -- forcing a much more implementation-based interaction. I'm finding that it 'gets in the way' much more often than it assists, where it differs from vim. (Heavy remapping helps, but it seems inherent in the model -- as it's designed to be mechanically consistent and not allow conditional actions based on edgecase scenarios.) |
Summary
This is a small nitpick I have with Helix, coming from Neovim. Helix counts the last newline character
\n
as a selectable character.Helix:
Neovim:
As seen above, the last character you can select in Neovim is the semicolon, but in Helix you can select the newline. This causes some keys, such as
a
orxc
to work differently than I would expect. See "reproduction steps" below.I recognize that this issue is a bit opinionated. If this is behavior is intentional, I'd like to know why. Thanks!
Reproduction Steps
Case 1
After pressing
a
, Helix recognizes that the next character after\n
is the}
on the next line, and inserts there instead.Normally, I would intend to append text at the end of line 2 instead of inserting at the start of line 3. This always annoys me, as I would have to go back up or just use
A
instead, whereas in other editors like Neovim I'm used to it appending text at the end of the line.Case 2
I often find myself having to change the whole line. In Vim this would be
cc
, and in Helix it intuitively should bexc
.However,
x
selects the whole line including the newline character, so when I pressc
it deletes that too and shoves the next line onto the current one:By the way,
gl
doesn't select the newline, which is inconsistent withx
. (Correction: see 2nd comment - there's a reason for the inconsistency)Suggestions:
\n
a
to stop at line boundariesx
to be likeghvgl
(go to line start, select mode, go to line end not including\n
)Helix log
No response
Platform
Linux (Arch x86-64)
Terminal Emulator
wezterm 20220624-141144-bd1b7c5d
Helix Version
22.05
The text was updated successfully, but these errors were encountered: