Jump to the next number on the line before incrementing

[antoyo]

Partially fix #1645

I noted that there's a bug that already exists in the current implementation regarding the selection being moved when the text length of a number is changed by incrementing/decrementing (when adding/removing a digit).

[archseer]

Rather than a separate method that has to check for \n & \r, you could modify find_nth_prev to use a matcher/pattern and pass in a text slice of a single line: text.line(n)

[antoyo]

Done.
This made the function find_next_char_until_newline a bit more complicated, though.
Any idea if I could have done it in a simpler way?

[archseer]

Sorry for the delay! I think this looks reasonable 👍

[silverweed]

Hi,
has this functionality been reverted? In my current Helix version (24.3) C-a and C-x only work for the item under the cursor. I can't find any other mention of this behavior more recent than this, nor any way to revert to the vim-like behavior in the documentation.

Edit: I found this later issue, but it's still not clear to me how to restore the vim-like behavior through custom keybindings.

[the-mikedavis]

Yes this was reverted in #4123. Having this exact behavior would probably require macro keybindings (#1383) and some scripting support (#8675). But manually you can search for \d+ and then increment/decrement

[silverweed]

Thanks for the answer.
Is there a reason why the old behavior was removed entirely rather than made non-default?
Considering helix is in a pretty good position as an actually viable vim replacement, it feels a bit frustrating to me that some of the vim capabilities I use frequently are simply not achievable in it. Even more so if they used to be achievable and then stripped away.

I understand the argument "predictability and consistency by default", but to me it doesn't warrant removing useful functionality without a way to get it back through customization.

I do think that macro keybindings would basically solve the problem, so it's good there is ongoing effort to that end (I really hope such a simple feature doesn't end up requiring custom scripting though).

[the-mikedavis]

As you say the reason is predictability and consistency. That's much more important to me than emulating vim. Increment/decrement behave unpredictably when we try to guess what number we're on or is nearby, especially when you have multiple cursors. Helix's editing model is to operate on selections and increment/decrement shouldn't be any exception. I won't accept a config flag for this behavior - the proper way to reintroduce this is macro keybindings and scripting.