I’m a bit confused about the implementation of the splitBlock command, and specifically this line.
It seems like it returns true regardless if the block above it passes the canSplit test. It return true regardless. Doesn’t this prevents using this in a chainedCommand if we want to have other command take over the operation if this one wasn’t able to do so? Shouldn’t a command only return true if it actually owned the action?
When it doesn’t apply, it will have returned false earlier. The if above this return just checks whether a dispatch function was provided.
But what if this can variable ends up being false?
Right, I see what you mean. I assume it’s written that way to avoid the more expensive checks in the query-only mode. Is this causing an issue in your setup?
It shortcuts the commandChain and therefore my commands are not getting a chance to run since they are supposed to run after these if they didn’t execute.
The expectation is that this one will usually be the last to run, since more specific commands are assigned higher precedence. What kind of command are you putting after it?
I can do that, I thought I will let the default actions try to work first, and only then try to do more specific tasks. The one I need to run is one that does technically the same operation (split a block) but one that due to schema’s nesting and complexity is not as trivial and requires some more logic to figure out how to lift a couple of levels before it can perform the action. I will reorder the operations. Btw, what’s the logic of order when multiple plugins register keymaps to the same key (say Enter), does the library automatically chain them, or should I deconstruct all the keys and chain them manually?
On closer look, it seems the command deletes the selection, scrolls the cursor into view, and does nothing else when the selection is in a block but it can’t split the current block. That does indeed come down to doing nothing when nothing is selected, but it’d be rather awkward, and potentially breaking, to redefine the command’s behavior at this point.
They each get a chance to handle the key, in order or precedence, and further handling stops when one returns true to indicate it handled it.
1 Like
I am having the same issue. My schema (the relevant part) has a title, abstract and content (consisting of paragraphs). When Enter is pressed at the end of the title or abstract, it should move the cursor to the next section - as a user would expect. However, splitBlock just swallows the input without doing anything. Moving it before splitBlock is wrong though, since in any case where the block can be split, it should split it instead of just moving the cursor, of course.
This patch should clean this up.