How to disable "crystal" task provider?
Syzygies opened this issue · 10 comments
For my Crystal VSCode projects, as for all of my projects, I have a default build task configured in my .vscode/tasks.json file. VSCode recognizes this default build task, for example when I inspect the Configure Default Build Task... command.
Nevertheless, when I invoke the Run Build Task... command, I get the error
The task provider for "crystal" tasks unexpectedly provided a task of type "shards".
According to VSCode documentation, it is the responsibility of task providers to provide a disable option. I could not find such an option for vscode-crystal-lang, reading through both its setting file and the GitHub documentation.
It is good practice to have a setting that allows users to turn off individual task providers
As an experiment, I copied a Crystal .cr file into the test section of an unrelated project. This alone does not trigger the Crystal task provider, but once I "accidentally" invoked the Run Build Task... command while this Crystal .cr file was in editor focus, I continued to get the "shards" error while invoking Run Build Task... on any other file type in that workspace. This behavior only stopped after I deleted the Crystal .cr file from that project.
This is unexpected behavior. For example, I might be writing a parser for which my Crystal .cr file is data, or an example, never meant to be compiled. Being clumsy enough to accidentally invoke Run Build Task... while this file is in editor focus should be expected user behavior. This shouldn't permanently change workspace defaults.
As Crystal itself has recently reached release 1.0.0, it should be expecting an influx of tourists. I am such a tourist. I have programmed in many dozens of languages, and I use VSCode for many kinds of work other than programming, such as authoring, and maintaining web sites. I'm simply not capable of remembering what is going to happen behind my back in all of these environments, so I have a standardized protocol for manual control of what happens when I invoke Run Build Task... across all of these kinds of projects. (I've also programmed in many editors, and this protocol allows me to switch editors at a whim, without many days of pain learning a new editor. .vscode/tasks.json is the only hook custom to VSCode. It finds my run environment, which depends on the project type.)
Perhaps I'm just lucky, but I've never before been prevented from using this scheme by the behavior of a task provider outside my control. Every other environment that I use respects my choice of default build task as configured in my .vscode/tasks.json file and recognized by VSCode.
Crystal files has .cr suffix, not .rb
Yes, four typos, fixed. Coming from Ruby. I experience this issue with .cr files, as must have been the case for me to be experiencing crystal errors.
Can please provide a link to the repo of the project where you are experimenting that problem and your vscode config, or compile the template for the bug report?
I'd be happy to simply get confirmation that the "crystal" task provider can't be turned off, or a pointer to where I missed documentation on turning it off.
I'll verify in the w.e.
I never used the Build Task on VS Code
I never used the Build Task on VS Code
I'm not sure whether you mean by this that you personally don't use the Build Task mechanism in your own projects, or that you're unaware of having programmed anything that would cause crystal-lang-tools to automatically entangle itself in the Build Task mechanism.
If it's the latter, I can confirm that crystal-lang-tools automatically entangles itself in the Build Task mechanism. I don't understand how this is happening.
If it's the former, that helped! I was trying to configure idiomatic VSCode by using their Build Task mechanism. That is of course unnecessary.
I found the following workaround: Remap "shift+cmd+b" to directly call my custom build task.
{
"key": "shift+cmd+b",
"command": "-workbench.action.tasks.build"
},
{
"key": "shift+cmd+b",
"command": "workbench.action.tasks.runTask",
"args": "run"
}
Unfortunately, keybindings cannot be local to a workspace. The above works for me because I have a .vscode/tasks.json file in absolutely every workspace, always defining a task called "run" that I consider to be my default build task. With this change, VSCode no longer considers this to be the default build task, so it doesn't automatically invoke unwanted side actions.
@Syzygies, I'm not the original writer of this plugin and I don't use VS Code Build Task in general.
As I say I will check the problem ASAP.
In the meantime you can find here how the plugin is configured:
https://github.com/crystal-lang-tools/vscode-crystal-lang/blob/master/src/crystalTasks.ts
I'm not sure whether you mean by this that you personally don't use the Build Task mechanism in your own projects, or that you're unaware of having programmed anything that would cause crystal-lang-tools to automatically entangle itself in the Build Task mechanism.
@Syzygies , sorry if I tell you this, but it seems to me that the way of expressing yourself is not very respectful of those who took over the management of this plugin (and of the entire organization) because for almost a year no one cared about it, for free and in it's own free time for passion alone. I replied as quickly as possible and as this is something I had not yet seen I promised to take care of it as soon as possible.
@Syzygies Since you don't share your task.json file or other configuration, I just try to reproduce with a new project:
crystal init app project
cd project
code .Inside code I used Terminal > Run Build Task (or cmd + shift + b)
Not having a command configured it offer the list of preconfigured tasks and I select Crystal:run
A file .vscode/task.json was created. Crystal Run work correctly.
I can select to change the default task with Terminal > Configure Default Build Task
I selected Crystal tool format and it worked.
The task provider for "crystal" tasks unexpectedly provided a task of type "shards".
Has something to do with the use of Shards Task. I will investigate when possible.
I think that tasks are working as expected.
If you want give more information and an example of a different behaviour on another plugin, feel free to reopen the issue.