Default launch configuration

[mjbogusz]

Hi, first, thanks for a great plugin - not having to switch between Octave GUI and VSCode is quite handy.

After some tinkering I've landed with the following launch configuration, which allows me to simply press F5 to launch the currently open file, even if it's using functions from other files in the same directory - similarly to how it works in the Octave GUI. Additionally I've managed[1] to get the QT plots to mostly[2] work under Windows.

"launch": {
    "version": "0.2.0",
    "configurations": [{
        "type": "OctaveDebugger",
        "request": "launch",
        "name": "Octave Debugger",
        "program": "${fileBasename}",
        "octave": "\"C:/Program Files/GNU Octave/Octave-6.3.0/mingw64/bin/octave-gui\"",
        "sourceFolder": "${workspaceFolder}",
        "workingDirectory": "${fileDirname}",
        "autoTerminate": true
    }]
}

Would you consider updating the default values for program and workingDirectory of the automatically-populated launch configuration? Additionally I think including this octave path example in the Readme would help other Windows users (the escaped inner quotes are crucial!).

I've seen the #51 but as it passes the whole filename along with the path to the program, I think it won't work if the program uses functions from neighboring files.

[1] After spending way too much time debugging and tinkering with environment variables - apparently simply calling octave-gui instead of octave-cli allows using QT without setting anything else (no env variables, no paths etc). [2] With autoTerminate: true the plot windows close as soon as the program ends, with false they stay on but closing them doesn't work (only stopping the debug); also their contents is not updating (e.g. resising the window doesn't resize the graph) - I believe this is #24?

[paulo-fernando-silva]

Hi! It's great you find the plugin useful. I'm sorry the help and launch configuration isn't perfect. I'll take a look at it as soon as I have time.

I think setting the default to vsc's ${file} should be fine. I do try to explain this in the help, but I believe it might not be clear enough. As it turns out

"program": "foo",
"sourceFolder": "${workspaceFolder}/A/B/C/"

is equivalent to

"program": "${workspaceFolder}/A/B/C/foo.m"

and "workingDirectory" is another optional parameter that if not set will be will default to the "program" directory. So, really "program": "${file}" is the only thing you should need to run the current file and any files in the same directory. But I'll add a reference to https://code.visualstudio.com/docs/editor/variables-reference

Regarding Qt, quoting from the help "plotting with qt or other plot frameworks might require you to add an infinite loop at the end of the program being debugged. For example: while(waitforbuttonpress()==0) pause(1) end which hopefully exits when you press a key but not when you press a mouse button. " You should try that with octave-gui, and you should have the best currently known debug experience. You can ignore the autoTerminate: false for now. It's not really useful in practice. I might remove it.

[paulo-fernando-silva]

Check version v0.4.18, and reopen this issue if it doesn't work for you. Thanks.

[mjbogusz]

I've verified this and indeed, "program": "${file}" works as expected 👍

As a side note, I've dug into handling background-opened plots a bit and it seems that a much better solution is to add a waitfor call at the end of the script:

h = figure();
plot();
% ...
waitfor(h);

With this the plot windows are fully responsive! I.e. I can resize the window and the plot redraws, I can zoom in etc. AND I don't use the not-so-beautiful infinite loop ;)

Note: only one waitfor call is required and closing any of the plot windows makes the script go through every waitfor anyway. HOWEVER calling waitfor(gcf) with multiple plots has yielded unpredictable behavior, e.g. after closing one plot window the second one become totally unresponsive and the whole octave-gui process has to be killed.

[paulo-fernando-silva]

I tried it and I like that solution. I've added it to the readme.md for other folks to hopefully also get to know about it. Thanks for sharing. I still didn't test it with complex qt UI. But it's good to have several options. 🙂