Add more rules for increment and decrement

[imadnyc]

As it is now, numbers have to be either decimal, 0bxxx or 0xyyy. It would be neat if there could be prefix rules per language. In verilog, decimals with fixed length are dictated like so: 3'b000. Helix doesn't pick up on this because it expects 0b. Similarly, it's 'h instead of 0x. I think the defaults as they are are sensible, but being able to add per language rules would be a real time saver. I also think that we should be able to have 1 zero-length prefix, so we could have say hex as the default behavior for <C-a> instead of just decimal. Similarly, maybe being able to modify behavior of switch-case so that we could flip 1's and 0's, though maybe that should be a separate issue.

[shaleh]

In theory treesitter's int_literal could be used to identify numbers. Not sure about the parsing and modifying though.

[zegervdv]

I'm also interested in getting support for different formats. I've created a neovim plugin before (https://github.com/zegervdv/nrpattern.nvim) and would like to add something similar to helix.

I'm wondering what would be the maintainers' preferred way to handle this? As I see it there are several options:

1. Hard-code the additional formats
2. Add per-language configuration with patterns
3. Could we do something via treesitter queries?
4. Leave this for a plugin

Option 2 could look something like:

[increment.verilog-based-hex]
pattern = "(%d*)'h([%x_]+)"
base = 16

[increment.verilog-based-bin]
pattern = "(%d*)'b([01_]+)"
base = 2

[[language]]
name = "verilog"
increment = ["verilog-based-hex", "verilog-based-bin"]

[the-mikedavis]

treesitter's int_literal could be used to identify numbers

int_literal is specific to whichever language uses that node. Many other languages use integer for the same meaning - there aren't conventions for sharing node names between languages. (Many parsers try to mimic the actual parser of the language, for example tree-sitter-gleam or tree-sitter-elixir.) Queries would be the flexible way to solve that with tree-sitter.

IMO this should be a plugin: it would be a fair amount of effort to build/maintain broad language support for a fairly small feature. It would be a good test of how much of the tree-sitter internals we can expose through a plugin interface in the future though.