Optionally regard underscores as word delimiters for movements.

[gibbz00]

This is a both a summary and an elaboration of a discussion held in chat, moved here for the purpose of gathering input from a larger audience. If I've left anything out, and/or misunderstood your messages; then feel free to express this!

The issue is that I often find myself in the need to edit snake_cased names. Say changing "message_not_noted_correctly" to "message_not_recieved_correctly". It could be done with a variation of 2f_f_c or 3t_mi_c, but this gets annoying very fast. It is extremely context dependent, inefficient, and unnatural for me to regard "message_not_recieved_correctly" as one word. Compare this with the muscle memory of the w, b and e movements, if only they would regard underscores as word delimiters. Old behavior could still be mimicked by using the WORD equivalents. Also, underscore word separation behavior unifies snake_cased with kebab-cased and slash/cased name editing. Another context that I suddenly don't have to think about. (The same could be said for camelCase and PascalCase namings if this feature is extended even further.)

I've had this behavior for a while, and I haven't looked back ever since. It's done by a patch that only removes || ch == '_' from chars.rs'

pub fn char_is_word(ch: char) -> bool {
    ch.is_alphanumeric() || ch == '_'
}

Old behavior is, nonetheless, a standard that most probably want to keep, but maybe not everyone. The main purpose of starting this discussion is for that reason twofold.

1. Present the topic for an interest check. Is this a feature that more people would be interested in?

2. Discuss implementation. I would propose adding a config boolean that enables this feature, but not by default. underscore-delimits-word = true in the [editor] section, for example.

Another recommendation was to make the movement behavior changes into separate commands. But this would require the feature implementors to recreate duplicates of move_next_word_start, move_prev_word_start, move_prev_word_end, move_next_word_end, extend_next_word_start, extend_prev_word_start, extend_next_word_end and extend_prev_word_end. Only to then require interested users to rebind all the respective values in their configs. (Not to delve into the headache it might create if the feature is extended beyond snake_casing.) Furthermore, I assume few would be interested in overriding only movements. And those that do want to only occasionally perform a snake_case movement with a specific keybinding, can already do this with '{f,t}_' etc. bindings.

Anyway, any feedback is much appreciated!

[kirawi]

Related: #2429

[divarvel]

I have the same need on both snake cased and camel cased identifiers where writing code.
Instead of modifying the behavior of existing movements through config, I would find dedicated inner-word movements convenient: it could handle both underscores and capital letters as word separators.
I think that would cover most of the developers-centric use cases while being reasonably self-contained

[rahil627]

yep, here for the snake_case problem, but surely other cases could use this solution.

i feel underscore-delimits-word flag is nice 'n general, and modular too(!), in case someone needs caps-delimits-word flag (camelCase/PascalCase) but not hyphen-delimits-word (hyphy-case!).

or perhaps there's a data container full of word delimiters already in the code, that we can expose and modify? It'll work for underscore and hyphen, but not camelCase/PascalCase.