Skip quick picker when there is only one task to select from

[Charles Milette (sylveon)]

I find it particularly annoying when it asks me what to select from when there's only one choice. This skips the quick picker and proceeds directly when there is only one task to choose from.

[Dirk Bäumer (dbaeumer)]

I had this a long time ago but then users complained that they want to have a consistent behavior independent of 1 or n tasks :-). So if we add this back it has to go behind a setting.

[Charles Milette (sylveon)]

Dirk Bäumer (@dbaeumer) Sure. Should this be enabled or disabled by default?

[Dirk Bäumer (dbaeumer)]

To not break anyone it should be off by default.

[Charles Milette (sylveon)]

Done.

[Dirk Bäumer (dbaeumer)]

Charles Milette (@sylveon) One minor thing. The setting should be in the task namespace not in the quickPick. However there might be a problem since tasks is overloaded with tasks.json. Have you tried tasks.skipPicker ?

[Charles Milette (sylveon)]

Dirk Bäumer (@dbaeumer) I added a tasks configuration namespace, but it effectively seems affected by tasks.json.

Using task instead of tasks as lazy fix would work.

[Dirk Bäumer (dbaeumer)]

Sorry for the long delay. Using task as a workaround makes perfect sense to me.

[Charles Milette (sylveon)]

Done

[Dirk Bäumer (dbaeumer)]

Charles Milette (@sylveon): I looked at the PR yesterday and I noticed that the tasks are now resolved outside of the quick pick. I see why this is happening however this results in the fact that the user has no progress feedback as long as the promise is resolved. This might not be so problematic for terminate and restart, however it will be for run since this on first execution might take some seconds. I need to think about what we can do here. Merging this is as is will make users unhappy where task resolving takes some time.

[George W Langham (GeorgeWL)]

Came from #51699

Might it make sense then, to solve the issue with quick picker if it's used for run, to add a settings option for run that's separate from the restart/terminate settings option?

Until can find a better solution that is.

[Isidor Nikolic (isidorn)]

Not for this milestone, pushing out to August

[Charles Milette (sylveon)]

Perhaps it's possible to do something like this. If the promise in the quick pick resolves without the user picking something, and there's only one option that results out of it, pick it. But if there's multiple, don't.

[George W Langham (GeorgeWL)]

Charles Milette (@sylveon) feels hacky, and against the way other stuff works, where if the user doesn't take a second action it cancels it.

[Alexandru Dima (alexdima)]

Cleaning up milestone

[Mark Murphy (markm77)]

Update 2: Alex Ross (@alexr00) Thanks for the response, I investigated this in more detail tonight and realised actually task had run to completion by the time I performed the restart shortcut. If restart occurred before completion the picker was not shown (desired behaviour). Apologies as I should have picked this up before contributing here. My personal preference would be for restart to behave the same before or after task completion but this is not worth a feature request....

---

Update: Alex Ross (@alexr00) would you like me to open a new issue for this comment as I don't think it's really in the right place? I would simply request that task keyboard shortcuts such as workbench.action.tasks.restartTask not show the picker when args variable is present (since user has already instructed task(s) to use).

---

Just hit issue in this area (actually probably more like #51699 but that has been deemed a dup of this).

I expected my workbench.action.tasks.restartTask shortcut to work the same as my existing workbench.action.tasks.runTask shortcut, i.e. use my task argument to directly restart. (Shortcut in both cases has args variable with label of single task.)

Very surprised to see the picker.... which means the two are inconsistent.

NB: I'm fine and even agree with a single task picker when selecting Run/Restart Tasks from UI, so this issue is a bit different. Maybe I should open a new issue (or would that be seen as a dup)?

[Dirk Bäumer (dbaeumer)]

Alex Ross (@alexr00) can I loop you in here?

[Alex Ross (alexr00)]

@markfinlabs, it sounds like you are seeing a different issue. Yes please do open a new issue for it and I will take a look.

[Alex Ross (alexr00)]

Charles Milette (@sylveon) thanks for working on this change! I have pushed a different version of it that doesn't resolve the tasks outside of the quick pick. The name of the setting is task.quickOpen.skip