Idea: Multiple switch alternatives
unphased opened this issue · 3 comments
I find that this plugin has a lot of powerful possibilities, and it makes me want to do a lot of things but we quickly run into ambiguities.
In order to address those ambiguities, the simple choices that we have in terms of controlling priority, although they are quite good and simple, reveal to me that "horizontal scaling" could be very useful. What I mean by this is that I think it would be powerful for me to be able to
- Define an arbitrary number of binds that trigger
Switch
ing - For each of them specify a definition list, and a priority scheme (by order in list, or by applying the smallest match -- actually I can suggest a few more possible options for this, how about next nearest match, seems useful to go along with https://github.com/AndrewRadev/switch.vim/wiki/Switch-next-in-current-line )
I think that the situation that I ran into is a good example that this proposal can address: as discussed in my issue #80 I have explored making Switch handle two very expansive classes of switching:
- The provided example which cycles between PascalCase, snake_case, CAPS_CASE, kebab-case, and camelCase, although this is provided as an extreme and silly example, I've found it to be both really cool and actually useful.
- Toggling a prefix and suffix to a symbol together (the example is
const
and&
for C++, used to change argument types between a value and a const ref)
Got them both working. However, it's not possible to define ahead of time whether I want to prioritize one over the other. It seems possible to derive intent with more precision than is possible now by making further use of the cursor position, but it wouldn't make much of a difference because we want to minimize the required precision of cursor positioning anyway.
So I think it would be great if I could make one map to do one set of switch custom definitions and another to do another. And I think it would be highly intuitive to organize these separate definitions along semantic lines or whatever makes sense.
I think that it is possible to do this external to the plugin by simply reassigning the g:switch_custom_definitions
when hitting these different bindings prior to executing Switch. So there doesn't seem to be any need to really add any abstraction layers in the plugin config for this kind of usage. What do you think?
So I think it would be great if I could make one map to do one set of switch custom definitions and another to do another.
I think that it is possible to do this external to the plugin by simply reassigning the g:switch_custom_definitions when hitting these different bindings prior to executing Switch.
There's no need to reassign the definitions. You can create the mappings yourself by passing along the definition dictionaries:
Lines 363 to 384 in 900c5d3
You can choose whatever combination of built-ins you'd like to use for any given mapping, from this list:
Lines 21 to 221 in 900c5d3
Would this be enough to do what you're looking for?
Yeah I should have looked more carefully in the doc, it would have obviated the need for this issue. thank you!
No worries, lots of settings and options in there to read :)