Skip to content
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

Wait until previous command is "done" before executing next command in sequence? #23

Open
macintacos opened this issue Aug 9, 2020 · 4 comments

Comments

@macintacos
Copy link

macintacos commented Aug 9, 2020

It'd be really nice if there was an option for multi-command to "wait" until whatever palette the previous command brought up is "dismissed" before moving on with the next command in the sequence (unless the previous command was "escaped", like if they hit the "ESC" key or clicked out of the prompt).

As an example, take the following command:

    {
      "command": "multiCommand.test",
      "sequence": [
        "workbench.action.quickOpen",
        "workbench.action.moveEditorToBelowGroup"
      ]
    },

I set this up because I want to search for a file, and then after I hit "enter" I'd like that file to be moved to the editor in the below group. However right now that's not how it works; the quick open panel opens, but then it immediately executes workbench.action.moveEditorToBelowGroup without waiting for me to actually search for a file.

It'd be nice if multi-command "knew" that it needed to wait for the quick open panel to be closed before moving on to the next command in the sequence. There isn't a way that I'm glossing over, is there?

@aterenin
Copy link

As a workaround, you can set the interval property to some positive number, so that the package waits a bit before executing the rest of the command.

I'm using this extension to work around very poor default behavior of the "Run Selected Text" command described in microsoft/vscode#43242 by running cursorDown after workbench.action.terminal.runSelectedText.

Waiting for previous command to complete rather than setting a specific fixed timeout interval would be ideal.

@ryuta46
Copy link
Owner

ryuta46 commented Aug 22, 2020

This extension waits until the previous command has finished.
But "workbench.action.quickOpen" command itself is finished when the small picker window is opened.

I checked the source code of quickOpen command in VSCode GitHub but I couldn't find a way to wait for the user to select a file, or get what that user select from an extension.

As another workaround, you can use workbench.action.acceptSelectedQuickOpenItem command when you select a file in quick open window.

For example, in settings.json

        {
            "command": "multiCommand.test",
            "sequence": [
              "workbench.action.acceptSelectedQuickOpenItem",
              "workbench.action.moveEditorToBelowGroup"
            ]
        }        

and bind it in keybindings.json

    {
        "key": "alt+t",
        "command": "multiCommand.test",
        "when": "inQuickOpen"
    },

and type alt+t instead of enter for selecting a file.
I wanted to bind this command to just enter key but it didn't work...

@ArturoDent
Copy link

Actually,

{
   "key": "enter",
   "command": "multiCommand.test",
   "when": "inQuickOpen"
},

works fine. But workbench.action.moveEditorToBelowGroup is a problem if you don't already have a split editor down. So if there is split editor, vscode will not create another group with that command.

For me if there is already a group down, the enter version works just fine.

@mjs271
Copy link

mjs271 commented Feb 4, 2022

To throw my hat in the ring, I would also love a feature that waits for a command to finish before moving on to the next one; e.g., like a bash script. My use case is with the LaTeX Workshop extension. I attempted chain together build and View LaTeX PDF file as:

{
    "key": "cmd+b",
    "command": "extension.multiCommand.execute",
    "args": { 
        "sequence": [
            "latex-workshop.build",
            "latex-workshop.view"
        ]
    }
}

However, it is typically the case that the pdf takes a moment to build, so the view executes before the build finishes. It is even worse if it's a first-time build, as an error is thrown because the pdf does not exist yet. Also, @ArturoDent, I dig the handle. Arthur Dent is my go-to placeholder name for most cases 🙂.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

5 participants