geddski
Second command of macro no longer executed after recent VS Code update
Env
Mac OS 10.13.6 (17G3025) VS Code Version 1.30.1 (1.30.1) Macros v1.2.1
Diagnosis and steps to reproduce
I use the macros plugin to replicate the cmd+e behavior of IntelliJ for Mac. This command opens the "Recent files" dialogue and shifts the cursor to the previously open file (i.e. the second item in the list of recently opened files, where the currently open file is first on the list).
To do this in VS Code, I created this macro:
// User Setings
...
"macros": {
"intellijRecent": [
"workbench.action.quickOpen",
"workbench.action.quickOpenNavigateNext",
]
},
...
And bound it to cmd+e in my keybindings:
// keybindings.json
...
{
"key": "cmd+e",
"command": "macros.intellijRecent",
"when": "!inQuickOpen"
},
...
Up until today, this was working as expected: pressing cmd+e would open the recently open files dialogue box and move the cursor to the second item in the list. Today, it is opening the recently open files dialogue box, but not moving the cursor to the second item in the list.
I tried these changes to see if they would return the expected behavior, but they did not:
"macros": {
"intellijRecent": [
"workbench.action.quickOpen",
"workbench.action.quickOpenNavigateNext",
"workbench.action.quickOpenNavigateNext"
]
},
"macros": {
"intellijRecent": [
"workbench.action.quickOpen",
"workbench.action.quickOpenNavigateNextInFilePicker"
]
},
"macros": {
"intellijRecent": [
"workbench.action.quickOpen",
"workbench.action.quickOpenNavigateNextInRecentFilesPicker"
]
},
It seems to me that the second command is not being executed in the new update for some reason.
Any advice about trying to determine the cause of the issue would be greatly appreciated. Thank you!
Might be related to #29, but my example was definitely working up until I opened VS Code today.
Comment on the issue at the VSCode repo: https://github.com/Microsoft/vscode/issues/65443#issuecomment-448922050
This is an issue with the extension. The promises returned by executeCommand are not properly waited upon here. It is a coincidence that this ever worked (due to the winjs promise implementation we used before).
