Add "additional options" to launch debugger with

[bitwes]

This PR implements #362.

This allows other VSCode plugins to fully leverage the debugger interface that this plugin provides. additional_options lets any other plugin specify whatever arguments it wants to send to the debugger.

Usage Example

class GodotDebugConfiguration implements vscode.DebugConfiguration{
    public type = "godot";
    public name = "Debug Godot";
    public request = "launch";
    public project = "${workspaceFolder}";
    public port = 6007;
    public address = "127.0.0.1";
    public launch_game_instance = true;
    public launch_scene = false;
    public additional_options = "";
}

private runGutThroughDebugger(options:string = ''){
    let config = new GodotDebugConfiguration();
    config.additional_options = "-s \"res://addons/gut/gut_cmdln.gd\"";
    vscode.debug.startDebugging(undefined, config);
}

[DaelonSuzuka]

This is just exposing functionality that the godot editor's debugger already has, right @bitwes? If that's the case, I don't see why this would be a problem. Improving interoperability is good.

I don't like to nitpick, but this commit was more difficult to read than necessary because it included a bunch of pointless whitespace changes.

[bitwes]

Pointless? POINTLESS!? Well, let me just hop up on my soapbox and.... j/k. I don't think it's nitpicky at all. It's exactly the type of thing I would enjoy arguing about for hours. I meant to remove it before submitting the PR. When I realized I hadn't I left it in and figured it would get addressed in the review. Should I remove it?

You are correct that this is just allowing other extensions to pass arguments through to the debugger. No real functionality changes. I wasn't sure if the initialConfigurations and configurationSnippets in package.json should get the "additional_options" or not. Those are settings that a user of this extension would set, and this PR is adding functionality for other extensions. It doesn't hurt, it just may require more documentation to avoid confusion. I'd be happy to add some documentation or samples to the README.

[DaelonSuzuka]

Sorry @bitwes, this PR slipped my mind.

I meant to remove it before submitting the PR. When I realized I hadn't I left it in and figured it would get addressed in the review. Should I remove it?

Well, I'll never tell someone not to clean up after themselves...

You are correct that this is just allowing other extensions to pass arguments through to the debugger. No real functionality changes. I wasn't sure if the initialConfigurations and configurationSnippets in package.json should get the "additional_options" or not. Those are settings that a user of this extension would set, and this PR is adding functionality for other extensions. It doesn't hurt, it just may require more documentation to avoid confusion. I'd be happy to add some documentation or samples to the README.

Do you think an end user would ever want access to this feature from in VSCode? Adding a field to the extension's settings is easy, but then that introduces a bunch of extra complexity if a the user defines additional_options and then an extension wants to define it too. Does one take priority? Do they both just get shoved in?

For that matter, what would happen if two different extensions want to define different additional_options? Is there actually a conflict, or does the last one to set the field "win"? I doubt there's vscode extension authors lining up to tap into this feature, but we should think it through anyways.

[bitwes]

Do you think an end user would ever want access to this feature from in VSCode?

Maybe. They could manually set options to run a standalone script (extends SceneTree) by setting options. It would be tedious to use it that way, but it is something they couldn't do before. I could see users wanting to specify options like --low-dpi or --print-fps. This keeps you from having to handle all the options explicitly. It's hard to say if this is worth the trouble though.

There could be a collision between plugin and user specified additional_options if it is added to the settings. I think you would want to use passed in options over settings. That would allow plugins to specify the parameters they wanted without having user parameters clash. This would have to be handled with a check. If there are options passed in, use them, otherwise try to load them from the settings. All settings should probably be treated this way.

// in server_controller.ts

if (launch_instance) {
	let godot_path: string = utils.get_configuration("editor_path", "godot");
	let force_visible_collision_shapes = false;
	let force_visible_nav_mesh = false;

	let more_options:string = additional_options;
	if(!additional_options) {
		more_options =  utils.get_configuration("additional_options", "");
		force_visible_collision_shapes = utils.get_configuration("force_visible_collision_shapes", false);
		force_visible_nav_mesh = utils.get_configuration("force_visible_nav_mesh", false);
	}
	
	...
	executable_line += " " + more_options;

I don't think you would want to have one set of "additional options" for the user and another for plugins. I could see this causing clashes in options which would be difficult for the user to figure out.

For that matter, what would happen if two different extensions want to define different additional_options?

I don't think there can be any clashes between plugins since they are passing the values in (as opposed to changing setting values).

[DaelonSuzuka]

It's hard to say if this is worth the trouble though.

I think we're all going with "not worth".

I don't think there can be any clashes between plugins since they are passing the values in (as opposed to changing setting values).

Sounds good to me.

@bitwes Thank you for your patience, both in explaining this feature to me in very small words, and for tolerating the delay in this PR getting reviewed.