Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This PR fixes #37 but includes a breaking change for the public
parseKeybinding
method. As I write this though, it occurs to me that I don't think that breaking change was necessary and I can probably revert that function back to the previous API if desired. Even doing that though, this PR changes the way Tinykeys processes the hotkey bindings and so is a breaking change.Whereas before this would trigger both keybindings when
g
and thena
was pressed:With this change it will only trigger the
"g a"
keybinding. This change also supports bindings in the formIn this case, pressing
"g"
will not trigger the"g"
keybinding until after the sequencetimeout
is reached. And pressing"g a"
will never trigger the"g"
hotkey. Basically, whereas before tinykeys only tracked the expected next keypress, with this change tinykeys tracks the entire sequence of keypresses and can use that to determine which keybindings are matches and which aren't. As you press keys, Tinykeys now knows if you are inside of a keybinding sequence and will disregard potential commands outside of the sequence.I think the behavior that this PR adopts is what most users would expect from this library. The major downside is that before the library clocked in at 530 bytes and after this change it clocks in at 620 bytes. Though it's quite possible some additional refactoring could reduce the size more. Size wasn't my primary concern when putting it together.
Let me know what you think. Feel free to make further edits.