spgennard
commented
2 years ago The quick summary is that an option did already exist many moons ago but was removed because people were enabling and got unexpected, undesirable behaviour and expected me to fix something that was not possible to fix.
Disabling the check will bring back the impossible-to-resolve undefined behaviour that comes from Visual Studio Code associating a language with a set of extensions. For example: If you click on a .cbl COBOL source, which extension would you expect to be activated.. both want to handle .cbl files.
The knowledgeable vscode developer already understands how some of this can be resolved through configuration but this does not stop multiple providers of vscode features from being triggered which generates multiple results or no results. In one case it caused a registered language provider to "recursively" generate results because it was being handled by another language provider when it expect itself to handle it, which is gracefully handled by vsocde but it did consume a lot of CPU/memory, so the user of the extension experienced a major regression in performance.
This is the "core" purpose of the check itself.
The next issue is what the extension provides, this extension provides language support for Micro Focus COBOL language dialects, which although GnuCOBOL has support for very limited Micro Focus COBOL dialect, it fails to provide a lot of the core language features such as micro focus specific syntax, threading syntax, object-oriented syntax, managed code syntax, numerous types of APIs, embedded preprocessors for html, dli, cics etc.. the integration with java, .net and a lot more.. honestly I have to stop with the list, otherwise it will start to feel like I am picking wholes in the GnuCOBOL implement but I have to be honest the GnuCOBOL Micro Focus dialect implementation does not compare to the real thing.
This extension has evolved to deeply support the true Micro Focus COBOL language, so if was enabled/relaxed; you will easily end up colourising, providing IntelliSense for things that do not match the compiler or debugger.
For me, it is like having a C++ language extension, enabling it for C when the compiler and debugger don't handle C++.
github-actions[bot]
As noted in the other thread: the gnucobol extension seems to miss a bunch of features that are available with this extension.
I would like to stay with the cobol extension, also when doing checks with gnucobol. The problem with that: While your gnucobol extension writes out a notification on each start, this extension deactivates itself as soon as a debugging extension for gnucobol (or is it any cobol extension but the microfocus extension?) is installed - even when I don't use it.
Please make this configurable. Maybe there could be a pull down "secure (disable when possible incompatibilities) [default]", "warning/output" and "disable check"?
Thank you!