VSCodium and set_env.cmd (from MinGW

[Arnold Trembley]

I'm starting a new Topic on this.

Simon wrote:
"If you want to run that in vscode just start set_env.cmd, then start vscode from there. This way you have everything set up and can use cobc/cobcrun from anywhere, including it's integrated terminal and possible extensions.

"As an alternative don't call cobc from vscode, but a wrapper script instead (that's how I did this when doing it), the gcx.cmd may be usable for this (I don't know).

"In vscode you'd install a COBOL extension, bitlang.gnucobol would be at least useful and also provides an error matcher for cobc. This can be used to not (only) compile via the terminal of vscode, but via a task: then ctrl+b and the program compiles and you see any issues in the problem pane of vscode and in your editor, too."
(end quote)

I must have installed VSCodium in an unusual way. If I use a Windows shortcut to run "set_env.cmd" and open a cmd.exe shell, the only way I can start VSCodium in that shell is with this rather long command:
C:\Users\Arnold\AppData\Local\Programs\VSCodium\VSCodium.exe

I would have expected VSCodium to be in C:\Program Files" or "C:\Program Files (x86)" which are already in the default PATH. But I can write a script to make this easier.

My VSCodium has a COBOL "folding" extension installed, but I can no longer find a "biglang.cobol" extension. Where do I find it for download/install?

It seems easier to me to just startup VSCodium, and then open a "terminal" from inside VSCodium. I had to switch the terminal from powershell to cmd. exe. Of course, the default folder for a new cmd.exe "terminal" is "C:\Users\Arnold" on my Windows box, but I can put a bat/cmd script there to call a specific set_env.cmd file. I can even have different scripts for different versions of GnuCOBOL. Then I can CD or use a script to navigate to a COBOL source or work folder and start compiling and testing. I can switch between the terminal and the editor all in the VSCodium window, and that works for me.

It's not the same as having a SUBMIT command in TSO/ISPF, but it's close enough.

Now if I can get the Gnu Debugger working in VSCodium, and get GDB support in my next GnuCOBOL builds, then I would have a full IDE with debugger. That's something worthwhile to try for.

[Simon Sobisch]

I must have installed VSCodium in an unusual way.

You've installed it the way Microsoft and the broad vscode community suggest you to do: "per user". This has the main benefit that the auto-update just works "directly" because you neither need admin privileges (also not needed for installation) or any UAC.

I personally like the "old way" of having a system wide-install; that is a different setup.exe.
You could manually uninstall the user setup, then install the system one if you like - all your settings and extensions and history should be kept as it is in the user profile (in the unlikely case that this has a separate name than the system wide just move the files from the user-install-profile to the other one).
I think in both install methods there is an option to put VSCodium (or codium) into PATH, so it would be just typing that (only useful if you commonly want to start it from cmd or powershell).

I can no longer find a "biglang.cobol" extension. Where do I find it for download/install?

You likely meant bitlang.cobol.
That's because the author asked to let it be removed from other marketplaces than MS's "for possible legal considerations" and VSCodium does not connect to the MS one but to OpenVSX (as Gitpod and other "online" vscode variants do).

If you want to, you could ask for the author for an update on this at https://github.com/spgennard/vscode_cobol/issues/245 (but don't mention my suggestion....)
The original issue was likely about signing the Eclipse publisher's agreement, but that's not even necessary as it could be published by a build service.

Until that is solved the only options are to:

• build the extension from the available source on your own
• download the extension from the MS marketplace

and use the "install from vsix" option.

It seems easier to me to just startup VSCodium, and then open a "terminal" from inside VSCodium

if this works best for you, then sure. In the common case I'd recommend to not do that because you then don't get the option of using "build" - with any errors, hints, and warnings shown in the editor; which is actually quite useful.

So... I've just checked how to do that with your packages:

At least for the old versions: add the following before ":: Compiler version output":

:: start executable as requested
:call_if_needed
if not [%1] == [] (
  echo environment is prepared:
  call :cobcver
  echo.
  echo now starting the requested %1
  echo.
  call %*
  goto :eof
)

Option 1:
a) start set_env.cmd, then from there start VSCodium
b) drag'n'drop the VSCodium.exe onto the set_env.cmd
c) create a shortcut of set_env.cmd and as its parameter have the VSCodium.exe
--> use that to start VSCodium with a specific GnuCOBOL version being active

Option 2:
start VSCodium, then create a task taking this script and cobc and whatever cobc commands, here a sample as "user task" (those are available in all projects)

        {
            "label": "compile with GC 3.1.2",
            "type": "process",
            "command": "D:\\dev\\GnuCOBOL\\GC312-NODB\\set_env.cmd",
            "args": [
                "cobc",
                "-g",
                "${file}"
            ],
            "problemMatcher": [
                "$gnucobol3-error-cobc",
                "$gnucobol3-warning-cobc",
                "$gnucobol3-note-cobc",
                "$gnucobol3-cobc"
            ],
            "group": {
                "kind": "build",
                "isDefault": true
            },
            "isBuildCommand": true
        }

Now you can execute this task (for user tasks everywhere, but for projects you'd likely want to specify include directories and other specific options [or use make all or similar as command], so you commonly would go with a workspace task then).

If there are problems you'd see those on the explorer view, along with the amount in each file, and see all in the problems pane where you can inspect / click to navigate them.

[Arnold Trembley]

Thanks, Simon.

That's a lot to take in. Not sure I completely understand how to do Option 1, but Option 2 might be possible. Where are user tasks saved and how are they named?

I have found that I can use a shortcut to set_env.cmd, and then start VSCodium from that shell by entering "vscodium.cmd", which is in the path.

[Simon Sobisch]

For option 1: you already have 1a) start set_env.cmd, then start vscodium.cmd; for the others you need to insert the lines I've mentioned above (I suggest you take them over for your next builds, too); then create your shortcut to set_env.cmd and edit, adding "vscodium.cmd" to the target (that's 1c, 1b is the same just "manually").

For option 2: press F1 (or CTRL+SHIFT+P), then type "tasks" and you can open the user tasks or workspace tasks (to create the later, just open your project's source folder with vscodium, then "save as workspace").

For more info about tasks see https://vscode-docs.readthedocs.io/en/stable/editor/tasks/ (but you also have code completion in there, just press CTRL+SPACE in the tasks.json or .code-workspace file and you get a description what you can add there (and do so by clicking on the suggestion or pressing ENTER).