-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Dynamic Macro #125
Comments
One obvious design change needed for this feature is changing the condition to activate the wrapper keybindings. This: {
"key": "ctrl+shift+a",
"command": "kb-macro.wrap",
"args": {
"command": "editor.action.selectToBracket"
},
"when": "kb-macro.recording && editorTextFocus" // LOOK AT THIS LINE!
} has to be changed to something like: {
"key": "ctrl+shift+a",
"command": "kb-macro.wrap",
"args": {
"command": "editor.action.selectToBracket"
},
"when": "kb-macro.active && editorTextFocus" // LOOK AT THIS LINE!
} . This requires existing users to manually modify their |
I have started the implementation of this new feature as a separate vscode extension in separate repository: The new extension Dynamic Macro declares dependency to this extension in its extension manifest ( |
Finally, the new version of this extension has been released! It includes brand new functionality Background Recording API that makes it possible to create keystroke automation extensions using this extension's capabilities. |
I've been asked if it is possible to implement Dynamic Macro on VS Code by its inventor @masui.
Dynamic Macro is a clever technique to perform repetitive operations.
See the paper (CHI 1994) for the details.
My understanding is that:
with Dynamic Macro, it doesn't require users to declare to start recording and to stop recording, instead, requires just to request to repeat the sequence the user has just repeated right before.
In order to implement it, the mechanism to record the keyboard inputs has to be always active rather than only during recording.
It means the wrapper keybindings is going to be used always.
This will be a big change to the internal behavior of this extension.
So, I think it is better to be an opt-in feature if implemented in this extension.
I will investigate further design impact and implementation.
The text was updated successfully, but these errors were encountered: