Limitations of `StateCommand`s when combined with `state.changeByRange`

I’ve come across a limitation when it comes to the interaction between running keybind with a StateCommands and using a state.changeByRange helper within that StateCommand.

Namely, the problem is that a StateCommand is expected to return a scalar boolean: false if CM should move on to other runners bound to that same key, or true if it should not. The issue I’m having is that when I enable multi-cursor mode, I want to operate over a number of ranges when the keybind is pressed. For some of these ranges, the a certain keybind’s runner might be “sufficient”, i.e. I don’t want that range to be processed by other possible runners with lower precedence. But for some ranges that high precedence runner might not be relevant, at which point I would want to pass those ranges on to the subsequent runners for that keybind.

So in essence, when I’m using a multi-cursor editor, I want a StateCommand to be able to return an array of booleans, one for each corresponding range. Ranges assigned as true are not passed on to subsequent runners, ranges with false are.

Does that make sense? I couldn’t see a way to handle this desired behavior with the existing implementation.

The convention is for a command to either apply to all cursors or to none at all. I can imagine different things happening for each cursor to get a bit confusing in some cases. Though maybe in other setups it is desirable, the base library isn’t built for this, and you’d have to move your per-cursor functionality into a custom framework.

Gotcha, thanks for the response. That probably makes sense.