Prevent cursor to accidentally move onto newline when moving vertically

[mitsuhiko]

Today if you use goto_line_end you end up resting on the last character of the line which also matches the behavior in vim. That means you use a to go into insert mode to append something. However it's also possible to move the cursor into the newline going up and down at which point it's necessary to use i to insert as otherwise you write into the next line.

I think it would be convenient to have an option that would generally prevent the move of the cursor onto the newline character by going up and down through the buffer. I ran into this trying to build line-restricted movements (#4204).

[erasin]

I think the editor render whitespace characters is more better, it can edit all character we see .

In the vim , if I want select the newline, need to use command :/\n and then delete or other operations.
In hx, we just select it and do something.

If you want to enter insert mode at the end of line and not use glli, we can reset a in keymap with config.

[keys.normal]
# use `li` or remap `after insert`
a = ["move_char_right","insert_mode"]

Maybe there are other ways

[CptPotato]

I'm afraid that this would be non trivial to implement and break the intended use of some commands (requiring inconsistent workarounds that fail easily).

For example to cut and paste a line you'd xd (cut) and p/P (paste). However this behavior relies on you being able to select the new line character.

When working near the line bounds I personally tend to use movements that work regardless of where the cursor is like these:

• I: insert at the start of the current line (but after any whitespace)
• A: insert at the end of the current line
• gli: insert before the last character (useful to add text before a ; in many programming languages)
• x_c: change the current line but keep the indentation
• ...

[mitsuhiko]

@CptPotato cut and paste is already quite tricky for line mode. A lot of functionality currently requires the use of v to go into visual selection first. See also the discussion about how x works #1638. Today If i use v$ (where $ is bound to goto_line_end) I do not have the newline included. At that point I already need to reach for X anyways to extend to the whole line.

I think the problem is not so much that you can move the character onto the newline, but that this is the natural resting position of the cursor when it moves between lines. If I move up and down the buffer I generally do not want my input to sit on the newline but the last character typed. That's also where gl moves me, or what x_c does. So what I'm looking for is not a complete prevention of moving into the newline necessarily (which would indeed require quite significant changes) but some internal state if I'm moving in visible text or if I'm moving newlines.

This would effectively mean that rather than tracking just the vertical position, helix would track additionally if I'm on the newline. Then if my character is actually resting on the newline then moving up and down also moves it to the newline position. This would also be closer to what vim is doing where it knows that if my cursor is resting on ($) it keeps aligning into the line end.

The only effect of this is a change to how up/down operates with regards to the newline. It would basically mean that for as long as I'm not already resting on the newline, I would not move onto it by going up and down on the buffer. It also means that if I'm navigating up and down on the newline, i will be resting again on a newline in the next line, even if that's further to the right than what I'm on at the moment (again, what vim does except different).

[mitsuhiko]

I implemented a prototype of this in #4204 now and I really like how it functions. I think it strikes a pretty good balance between how helix works and how vim works. It causes left/right movement to be contained within the line you are on, and the vertical movement is either staying on the newline character or left of it.

[ArijanJ]

Any progress on this? The default behavior is very jarring.

[k3d3]

The two situations I run into this is:

• Using the mouse to click past the end of the line, then pressing a
• Press End on a line to go to the end of it, then using j/k/up/down to switch to a shorter line, then pressing a

In both of these cases, if I type anything, that text ends up being entered at the start of the next line, not the end of the current line.

This feels weird (and possibly unintended?) to me, especially because if I hit End on a line and press a, the text gets added to the end of the current line as I would expect.

Additionally, when I do this, I cannot use l/right to move past the end of the line, to get into the same position as with the two bullet points above.

---

I like mitsuhiko's PR #4204, and may end up using it myself, however I believe it addresses different behaviour than what I've mentioned above.

(I'm not sure if my comment warrants a new issue, or if it fits here)

[pantos9000]

People know this already, but for a better overview and for people joining the discussion:

PR #4204 was closed because the movement implementation changed internally. The changes are picked up and applied for the new implementation in PR #10576, which also addresses the append behavior with a that is mentioned above.