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

Improvements on DAP integration. #22

Open
undyamon opened this issue Jan 17, 2024 · 1 comment
Open

Improvements on DAP integration. #22

undyamon opened this issue Jan 17, 2024 · 1 comment

Comments

@undyamon
Copy link
Contributor

I was playing around with nvim-dap and its integration with this plugin and I think I found a couple of bugs.

local dap_config = dap.configurations[command.dap_name] -- Try to get an existing configuration
dap.run(vim.tbl_extend('force', dap_config and dap_config or { type = command.dap_name }, {
name = command.cmd,
request = 'launch',
program = command.cmd,
args = args,
cwd = cwd,
}))

  1. According to nvim-dap documentation, dap.configurations.<filetype> is a list of configurations. In case the list is present, it is force-updated in line 121 to include a bunch of key-values; this results in a table with said key-values and a bunch of configurations. In particular this table doesn't have type defined, resulting in an error from nvim-dap.
  2. In nvim-dap configurations, name has to be a string, while program can be a function as well. Assigning command.cmd to both name and program prevents the user from using a function to compute program on the fly.

For (2), I would give a custom name only if no dap configuration is present; in that case it can be moved with type and be something like 'tasks-' .. command.dap_name or similar.
For (1), I'm not sure why one would need multiple configurations so I don't know how to go about it, or which config to choose when multiple are present.

@Shatur
Copy link
Owner

Shatur commented Jan 17, 2024

Thanks! I implemented this plugin long time ago, probably something changed.
I agree with the suggestion for (2). For (1) I would just pick first and warn if there are multiple ones.

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