Weird behavior with high number modifiers about helix HOT 11 CLOSED

This is it dropping the oldest(left most) digit:

This is it capped:

And this is it returning the previous good value(I keep pressing but as it keeps returning the same value there is no change in displayed number):

from helix.

Can you take a screencap of it happening? I tried the steps, but I got the expected appending, and the expected view that follows the cursor beyond the normal screen size, and the digits showed what I expected.

Are you using soft-wrap?

from helix.

Yes I'm using soft-wrap. I'm curious, how that would affect it?

from helix.

Also, I didn't have any relevant lines in my log before, but now this happened in the last few minutes:

2024-06-10T20:52:22.003 helix_core::syntax [ERROR] TS parser failed, disabling TS for the current buffer: Err(Cancelled)

from helix.

Ah, I misunderstood the reproduction steps. I thought you were typing in the normal buffer. When I saw gg I just assumed so. I skimmed passed the in normal mode part.

The last part though, gg, spam 2, j (number freezes, j doesn't work), j works for me.

from helix.

Ah yeah sorry, wasn't quite sure how to refer to that number.

from helix.

Checked in debug mode it panicked with: attempt to multiply with overflow.

I can probably get a pr for this with a fix, but what behavior should be desired? If we cap it to digits then it could go from 1111111111111111 and then suddenly switch to 999999999999999. If we go by actual length, then we would need to turn the number to a string to check it, and then if it goes over, should it drop the left most digit, as the displayed value grows right, or should it just return the previous last good value(which is just functionally dropping the right most digit)?

from helix.

Oh, very cool! My vote is on dropping digits, just because it has a clear visual indication of where your inputs are going in case you think you're in insert mode. (because who's really going to need precise numbers in the trillions?)

from helix.

On the other hand, the standard use case for a count would never encounter an overflow. So not sure its worth adding a branch and an allocation each use to solve something that's likely to never be encountered when using the feature. Before submitting the pr, ill wait for feedback from the core maintainers to see what they think.

from helix.

@kirawi or @the-mikedavis some direction would be helpful, if possible.

from helix.

I think it's reasonable to cap to a high number like 100,000,000. If a keypress of a number would make the count exceed that value we can just ignore the keypress. This situation shouldn't come up often so I'd like to keep it as simple as possible.

from helix.