helix
helix copied to clipboard
Increase/decrease number commands inversed for some HTML
In an HTML file with:
<img src="https://small-tech.org/videos/small-is-beautiful-22/poster.jpg" alt="" width="640" height="360">
10
Ctrl+a decreases the 22 to 21. And Ctrl+x increases the 22 to 23. (This is the reverse of what normally happens.)
However, if you try them on the 10, Ctrl+a increases it to 11 and Ctrl+x decreases it to 9 as it should.
Version
helix 22.05 (f0fb3407)
Confirmed bug also exists in latest (helix 22.08.1 (714db9c6))
C-a/C-x are interpreting the 22 as negative because of the leading dash.
@the-mikedavis Interesting. My intuition would be that when it’s part of a string, the dash would be seen as an delimiter instead of a minus sign. I don’t really see any use case where you’d want a number that’s part of a string to be interpreted as a negative number.
The smartness for whether the negative sign belongs to the number could be improved. Whether the negative sign belongs may depend on the preceeding character. If it's whitespace or any sort of punctuation, it most likely belongs to the number. If it is a character then it may not. It may be complicated to decide in particular with dates.
It may be complicated to decide in particular with dates.
I think it should be fine as dates are handled separately in helix-core/src/increment/date_time.rs. Increment first tries to treat it as a date, and then if that fails it treats it as a number.
https://github.com/helix-editor/helix/blob/19384cc3a18ad56e3f06ecc43cf91c1641f36f90/helix-term/src/commands.rs#L4793-L4800
https://github.com/helix-editor/helix/pull/4123 removed the code that tried to automatically detect the range for increment/decrement. With that change, you should now select the range you want to increment/decrement. Selections for numbers could be an interesting textobject to add (although maybe it's possible to add a simple textobject like that with regexes based on macro keybindings (#1383) and alternate search mechanisms (#5672)). But in any case, the detection shouldn't cause confusing cases like this anymore so I will close this out