You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
To build really powerful submodes it would be nice to be able to register setup and teardown functions that get called on_entering and on_leaving. I know that especially the setup part can be achieved with a workaround (defining a rhs command in the enter_with function), but that's a little hacky, as I am pretty sure you didn't intend this feature to work this way. I assume it would be enough to implement two dictionaries where the submode's name is the key and the value is an array of funcrefs to be called in the respective parts.
Possible use cases would be to activate/deactivate different highlightings or opening/closing a split window that holds additional information you could use during your submode's activity etc etc.
The text was updated successfully, but these errors were encountered:
Since enter_with has an optional {rhs}. When are setup functions called? Before {rhs}? After {rhs}? It depends on purposes. So we have to support both.
I always think of the optional {rhs} as the first command that should be called INSIDE the submode. Taking a pseudo-example
submode movement enter_with '<esc> j', '5j'
submode movement map 'j', '5j'
5j is the rhs here, which is also the regular submode mapping for j, which I already want to be called when I trigger the submode.
A setup function would be called before it, before the rhs is executed, as it just sets up the submode.
What purpose do you have in mind for calling it after the rhs?
Feature proposal mentioned in #13
To build really powerful submodes it would be nice to be able to register setup and teardown functions that get called
on_entering
andon_leaving
. I know that especially the setup part can be achieved with a workaround (defining arhs
command in theenter_with
function), but that's a little hacky, as I am pretty sure you didn't intend this feature to work this way. I assume it would be enough to implement two dictionaries where the submode's name is the key and the value is an array offuncrefs
to be called in the respective parts.Possible use cases would be to activate/deactivate different highlightings or opening/closing a split window that holds additional information you could use during your submode's activity etc etc.
The text was updated successfully, but these errors were encountered: