Increased Editing Speed in Helix with two important changes to j and k movements

[nik-rev]

If helix made two changes to j and k it would seriously compete with Vim in terms of keystrokes needed to vertical action

1. <count>j and <count>k acts like <count>gj and <count>gk.
2. j and k both should select entire lines when used

Now I'll explain why both of those make sense and are beneficial.

<count>j and <count>k acts like <count>gj and <count>gk

Currently, j and k do not ignore soft wrapping. This is useful when moving line-by-line, but when using relative lines and prefixing with a <count> it is really annoying because you may want to move 22 lines down but because 1 of those wraps over to 3 lines you have to count how many lines wrap and then do mental math to write the correct count like 25j.

One could write 22gj instead of 25j, which does ignore wrapped lines. However that is one extra keystroke which could be removed. Instead, I propose that when we add a count to j or k motion, they will ignore wrapped lines.

The reason why this is going to be a useful change is because almost all of the time, this is the behavior that you want. When using relative lines and prefixing j and k with count, you expect to exactly go to those lines and not the current behavior where the movement can be "absorbed" by wrapped lines.

Some people use jjjjjjjjjj and kkkkkkkkkkk, and that's fine. But a lot of people including myself use relative lines to travel vertically at high velocities and specifically prefixing with a count. Currently you have to use <count>gj and <count>gk to achieve this, but <count>j and <count>k would be a lot more nice.

If this change were to be added, it would reduce the amount of keystrokes needed for a very common movement from 3 -> 2. This is a huge improvement with basically zero downsides.

j and k should select full lines

If I type j, it just moves my cursor to the line below. One very common movement in Vim is dj and dk which allows to delete the current line and the line above/below. This functionality can be implemented in Helix if j and k actually aligned with Helix's editing model, and it would be kd and jd instead.

Additionally, if I type 22k it should select 22 lines up, so then I can do 22kd which has the same effect as Vim's d22k. This allows to manipulate large chunks of text vertically and is something I constantly use in vim.

Conclusion

The first change is a very useful QoL that reduces the amount of keystrokes needed for a common action from 4 to 3, with no downsides

The second change would align with Helix's editing model. I don't understand why j and k don't already behave like that, and plus it will significantly lower the amount of keystrokes needed to do vertical text manipulation.

Thank you for reading, have an awesome day. I really love this project and I think it's editing model is extremely intuitive. If the above two changes are added, Helix can actually compete with Vim in terms of keystrokes needed to perform simple actions.

[RoloEdits]

Deleting lines, to me, seems pretty well covered by xd. Having movement keys always select seems like it would be more of an hindrance in movement to movement workflow, and there is the multicursor factor to take into account. There are a lot of times I am block editing and the selection process requires to select up or down. The always select would instantly hinder this workflow. As for movement, id also suggest trying jumpwords with gw. "Scrolling" up half pages can be done with Ctrl-u/d. With jumpwords and half-page scrolls I don't find myself using jk to traverse far.

The count modifier change I can see making sense. But I think there are better ways to traverse.

[schlich]

I'm using ctrl-u/d heavily but my fingers hate it.

i'm trying to get used to the [ and ] modes but not quite used to the eager selections. what kinds of advantages does [+F have by selecting the whole previous function instead of navigating the cursor to the beginning or end? is there any way to simply navigate to the beginning or end of the function/paragraph/whatever you're currently working on?