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

rfc: configuration providers #1226

Closed
mfussenegger opened this issue May 26, 2024 · 1 comment
Closed

rfc: configuration providers #1226

mfussenegger opened this issue May 26, 2024 · 1 comment

Comments

@mfussenegger
Copy link
Owner

Problem Statement

Currently you always need to be in a file with the right filetype to start a debug session.

This works well enough for many work patterns, but on some type of projects it's common that you're in another buffer. E.g. you might want to start django while editing a HTML file. Or you're in the REPL and want to start a debug session again.

Possible Solutions

Showing all global configuration options is probably too much, but a compromise could be to:

  1. Show all local configurations (from .vscode/launch.json)
  2. Show global configurations related to the filetype as is.
  3. Provide a provider.configs extension points for additional sources. (E.g. some language servers/plugins provide functionality to discover entry points)

Always doing 1) could also remove the need to specify a filetype/debug-adapter-type mapping as part of the load_launchjs call.

  1. and 2) would be implemented using the provider/configurations extension points, that means people could also unregister or replace them.

For 3) I'm thinking of something like:

local dap = require("dap")
dap.provider.configs[plugin_name] = function()
    -- can return a list of configurations, or a thread that will yield the list
end

(I'm also thinking of other types of providers, like variable formatting or yank-as-<format> functionality - hence the provider namespace. Or dap.ext.?)

I'd like to get some feedback on this.

Considered Alternatives

No response

@mfussenegger
Copy link
Owner Author

Implemented with #1237

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

1 participant