Optionally allow launch.json to overwrite the debugee configuration
adinb opened this issue · comments
Problem Statement
Oftentimes, the debugee configuration differs from project to project. By optionally allow launch.json to overwrite the debugee configuration, one can easily switch from one project to another without cluttering the configuration list, as the list will only show the relevant configurations for the project.
Ideas or possible solutions
One possible solution is to add an overwrite
flag at the end of dap.ext.vscode.load_launchjs
arguments as follows:
load_launchjs({path}, {type_to_filetypes}, {overwrite})
If the overwrite
flag is true
, then the loaded launch.json overwrites dap.configurations[filetype]
. Else, it extends dap.configurations
.
Currently I'm using that approach in my setup, and it's working well for me.
Isn't it possible to clear out the existing configurations before calling load_launchjs to accomplish the same?
What would be the key, name and type?
Isn't it possible to clear out the existing configurations before calling load_launchjs to accomplish the same?
You're correct. I just find it neat to include the functionality in the API as I think it's a common use case. I don't find this as a deal breaker though, as it's quite easy to script it ourselves outside the plugin.
What would be the key, name and type?
At the moment I wipe the configuration based on the file type. For example, if I load the following launch.json:
{
"version": "1.0.0",
"configurations": [
{
"name": "Debug MyApp",
"type": "go",
"request": "launch",
"program": "github.com/me/myapp/cmd/myapp",
"args": [
"-f",
"config.toml"
]
}
]
}
dap.configurations["go"]
will be wiped and replaced with the one from launch.json
A bit tangent, but I wanted to be able to easily keep the predefined global configurations (for example, the ones loaded during startup from lua files), while also able to freely swap launch.json
files if that makes sense. However, I settled on the approach I explained in the original post as it's good enough for my use case.
I'm not too keen on adding parameters to do something that can be done in a single line up-front
What I could imagine is either changing the behavior to try to merge configuration entries by type and name or to have an additional method that does that.
Understandable. I'll close this issue.
What I could imagine is either changing the behavior to try to merge configuration entries by type and name or to have an additional method that does that.
I'm also looking at this. Maybe I'll be back if I have something in line with that, but anyway thanks for your response!