Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Drop outdated launch.json entries on load_launchjs #1065

Closed
moetayuko opened this issue Oct 22, 2023 · 3 comments
Closed

Drop outdated launch.json entries on load_launchjs #1065

moetayuko opened this issue Oct 22, 2023 · 3 comments

Comments

@moetayuko
Copy link

Problem Statement

load_launchjs only adds entries to dap.configurations, but it does not drop outdated ones. For instance, if an entry named "foo" is added and renamed to "bar" later, both "foo" and "bar" will appear in dap.continue(), but we expect to have "bar" only.

Possible Solutions

No response

Considered Alternatives

No response

@mfussenegger
Copy link
Owner

This is because configurations can be added from other sources and therefore load_launchjs doesn't know if a entry disappeared or not.

If you know that you're managing all configurations via launch.json files you could reset them beforehand manually, e.g.:

local dap = require("dap")
dap.configurations = {}
require('dap.ext.vscode').load_launchjs()

One other option that has been on my mind for a while now is to have .continue() discover configurations at runtime in addition to looking up entries in the dap.configurations table. Then it would always read the configurations from the file again and show them in addition to any static definitions.

But if I add that I'd also like a extension mechanism for it, to allow plugins to discover additional configurations too. I haven't made up my mind yet how that should look like and currently isn't a priority.

@moetayuko
Copy link
Author

This is because configurations can be added from other sources and therefore load_launchjs doesn't know if a entry disappeared or not.

For load_launchjs only, I think we may maintain a list of old task names. Every time after scanning launch.json, we can compare the current task list with the old one and remove invalid tasks accordingly. But when combined with other sources, extra care may be needed, e.g., when different sources provide tasks with the same name.

One other option that has been on my mind for a while now is to have .continue() discover configurations at runtime in addition to looking up entries in the dap.configurations table. Then it would always read the configurations from the file again and show them in addition to any static definitions.

But if I add that I'd also like a extension mechanism for it, to allow plugins to discover additional configurations too. I haven't made up my mind yet how that should look like and currently isn't a priority.

Dunno the internals of this plugin so can't comment much. Maybe having different sources maintain their own static task lists, and merge them in .continue() at runtime?

@mfussenegger
Copy link
Owner

With #1237 the launch.json is now loaded implicitly without merging into dap.configurations - that means you can drop the load_launchjs call from your configuration.

Given that dap.configurations is no longer modified, old entries should no longer show up.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants