Changed task names to short descriptions

[TomByrne]

vscode uses the task name as an ID. Changing the task names from a list of arguments to a simple description (Buidl, Test, Run, etc) allows other tools to call these tasks without having to know which target is currently selected (or whether in debug mode). If there's anything that is hooking into the tasks with their original name I can add these renamed versions as additional tasks (and retain the old task names). If this is the case though I'd probably suggest adding tasks for all targets (and debug/release), not just the selected ones. This would allow external scripts/tools to use their own logic to determine the intended settings.

[Gama11]

I would be surprised if you have to rely on the task's name for that (which also shows up in the user interface, so it would be annoying not to see the selected target there).

You should be able to check task.definition.command. You may have to cast definition to a LimeTaskDefinition first: https://github.com/openfl/lime-vscode-extension/blob/ec813fe9d2df3a1a94067b2a9b638c650b5f78f4/src/lime/extension/Main.hx#L744-L747

[TomByrne]

For things like keybinding (and other UI tools, like the commandbar extension), the syntax to run a task is workbench.action.tasks.runTask|MyTaskType: MyTaskName.

So to bind the current tasks, it's something like: workbench.action.tasks.runTask|lime: build controller.lime html5 -debug. As you can see, this isn't really useful as you'd need to map a different key combo for every permutation of lime's command line.

You mention that it shows up in the user interface, but it already is shown in the target/build selection buttons at the bottom left, so I'm not sure I agree that that it is annoying to omit this info from the task name.

Either way, we can have the best of both worlds by adding both options. I've rolled back the previous commits and added functionality, let me know what you think.

[Gama11]

I wouldn't describe this as the best of both worlds, duplicating the tasks is likely to lead to a lot of confusion as to what the difference between the (identical) tasks is. :) I'd personally prefer the previous approach of only using the command name to that. In the end it's up to @jgranick though.

Btw, while it's true that the target and debug/release can also be seen in the status bar, with "Edit Target Flags" you can add additional command line parameters (-v, -clean or whatever) where it's not as easily appearant. I think the arguments should still show up in the terminal though.

[TomByrne]

Yeah, I agree with all of this. Yeah, the actual arguments do get displayed in the terminal. @jgranick ?

[Gama11]

Have you considered opening a feature request on the commandbar extension that would allow a regex match on task names, rather than requring an exact match? You could then easily look for a task that starts with lime: build (~/$lime: build/).

That's how I did it for vscode-terminator.

[TomByrne]

The workbench.action.tasks.runTask is not part of the commandbar extension, it's a core Code feature, meaning that any extension integrated with tasks will have a hard time calling the existing tasks.

This is especially true for key bindings, which are not an extension and which I'm guessing many devs would like to use with Lime. Here's a screenshot of my UI using my modified version of this extension, along with the commandbaar extension. I think it is very clear at any time which target you are working on, as it is shown in both the status bar and the output panel, just not in the task dropdown.

[jgranick]

This is done in current dev versions

EDIT: Happy to discuss opinions on what name we should use -- currently it looks like "lime: build (active configuration)"