}
}
]
}
I can't believe that that the file's name has to be hard coded here.
I don't understand why I need to write this file at all since I installed the nim plugin.
Best regards Paul
I just right click and "Run selected Nim file" or F6. From then on I do press "up" and "enter" in the console that opens.
Why do you need tasks? What advantages do tasks have? Never used them.
When I was doing advent of code this year, I used a .vscode/tasks.json in the repo like this:
{
"version": "2.0.0",
"tasks": [
{
"label": "build",
"type": "shell",
"command": "nim newest --hint[Conf]=off",
"group": {
"kind": "build",
"isDefault": true
}
}
]
}
Once new days stopped appearing and I wanted to work on older ones, I switched to an approach more similar to what @treeform suggested where I ran something like nim day 18 in the console, and then whenever I made changes I'd just go to the console and do "up" and "enter" (note that nim day was another script that did some simple things like determine the desired input and output file locations and set flags).
@kcvinu note that you can create .vscode/tasks.json or config.nims or .nimble files in a repo and they can contain scripts that will only be relevant for that repo. For example at the root of your repo create .vscode/tasks.json, and copy the above into it, but change the command to something like: nim c -r path/to/your/main.nim. If you do that, then the setting "nim.buildOnSave": true, should call it every time you save a nim file in that repo.
Ok, I see. Tried it and it works. Thanks!
Cheers Paul
P.S.: The reason for my tasks file is the documentation of the nim plugin, BTW.
Genuinely curious, why would VS Code tasks be preferable than a nimble file?
You can't run VS Code tasks in CI for example which ultimately your local testing should be a mirror of.