CKolkey / ts-node-action

Neovim Plugin for running functions on nodes.
359 stars 20 forks source link

Add setting to set possible `cycle_case` formats (+ their priority) #15

Closed primeapple closed 1 year ago

primeapple commented 1 year ago

I would like to customize the possible cycle_case formats for variables.

So for example in JS I only use camelCase and SCREAMING_SNAKE_CASE. I would like to set this like

actions.cycle_case({'camel_case', 'screaming_snake_case'})

For python I also need normal snake_case. However I use camelCase there very seldom. This would look like

actions.cycle_case({'snake_case', 'screaming_snake_case', 'camel_case'})

Here it is important that we try to remember the priority.
When I execute the action on a variable SOME_VARIABLE I want to to change to the first other case option that is not it's current case option and was not tried yet. So it would change to someVariable. If I hit the action again it should change to someVariable.

It might be that this is to unintuitive. I'm also fine if I can just set the order. So we always pick the style that comes right after the current style given parameter list. So for SOME_VARIABLE it should become someVariable.
If we go this route maybe we could also add another parameter, backwards to the cycle_case() function, that allows for a forwards and backwards mapping (Maybe <M-A>, <M-X>?)

Ideally use constants for the different styles, not as I did with strings ;-)

CKolkey commented 1 year ago

I definitely like this idea. Let me see what I can do.

CKolkey commented 1 year ago

I've come up with a way to handle this that I'm pretty happy with. The problem with a priority-list approach is remembering state. Each node action is a pure function without state, so there's no way to track which is "next". What I've done is basically re-write the current implementation to allow a user to pass in which formats they want, or supply their own via a table with a standard interface.

I dig the backwards/forwards idea, but I'm going to punt that for now. The main idea behind this plugin is a single entry-point function that applies a different function based on the node type, and at least for now, there's not an easy way to bind a specific function directly. Lets see - if you feel like exploring that, I'll happily look at a PR :)

CKolkey commented 1 year ago

Thanks again for the great suggestion!