[Bug]: numbers in hex values are not ignored

[leg7]

Bug Description

Hey it's me again.

since the fix for bug #31 now motions in hex colors stop at numbers:

I would expect motions to ignore this gibberish but maybe it would be to hard to implement the skip efficently? I know vim knows how to recognize hex values natively because <C-x> and <C-a> can decrement and increment these respectively.

Reproduction & Sample Text

Code to try it out:

$selection  =    eceff4
$background =    2e3440
$red        =    EF5350
$green      =    66BB6A
$yellow     =    E2C12F
$blue       =    42A5F5
$mageta     =    AB47BC
$cyan       =    26C6DA
$foreground =    D8DEE9

neovim version

0.9.4

Special Settings

No response

Make sure you have done the following

• [X] In case I have an issue with using the motions in operater-pending mode (cw, de, …), I read the notes on operator-pending mode in the README.
• [X] I have updated to the latest version of the plugin.

[chrisgrieser]

Well, fixing it is not the issue. The issue is rather deciding how exactly the nvim-spider is supposed to behave. Ignoring things that look like hex values is very problematic, since there are a lot of ambiguous cases. For example, is 123456 a hex value or a number? Is face01 a hex value or a variable name? And what about other things like hashes?

Like, there are really a lot of edge cases here. When in doubt, I'd prefer to go with the simple solution (nvim-spider goes by subwords/digits, regardless of whether they might be hashes/hex codes etc.), since that makes nvim-spider's behavior most predictable. Adding ambiguous edge cases where the plugin should behave differently a problem, since users with variables like face01 will be confused why nvim-spider behaves differently here than with back01.

I think the current implementation of nvim-spider with the change suggested in #31 makes most sense, and I think I'd prefer it over adding ambiguity via things like hex codes. I'd be open for suggestions though if you can provide a detailed and unambiguous specification how exactly nvim-spider should treat numbers.

[chrisgrieser]

You might be interested in the custom-pattern feature I recently added, which allows you to define a set of patterns defining stopping points yourself: https://github.com/chrisgrieser/nvim-spider/blob/main/README.md#advanced-custom-movement-patterns

[gokberkgunes]

I am facing this issue as well. I have hex codes that start with # such as #e1f0aa, and nvim-spider thinks this is a camel case. Right now, these words nvim-spider thinks camel case appears as false positives.

At worst condition, I believe nvim-spider should avoid strings starting with # as camel case. Moreover, a setting that would consider a word with numbers as a whole word could be implemented.

[chrisgrieser]

@gokberkgunes Those aren't false positives, nvim-spider works that way by design as it is intentionally language- and syntax-agnostic.

However, as mentioned in the comment right above yours, you can customize spider to have the behavior you prefer by using custom movement patterns.