nvim-dapconfig

[punowo]

What? similar to nvim-lspconfig, for Debug Adapter Protocols so you can use them with https://github.com/mfussenegger/nvim-dap

Why? My assumption which may be wrong is that for completion, most people these days just go with coc.nvim, some are not comfortable with the fact that coc uses node and try looking for alternatives, eventually going for stuff like nvim-cmp.

While a little harder to config, it's still a lot more streamlined using nvim native lsp client, nvim-lspconfig, nvim-lsp-installer and will probably become the defacto to way to configure lsp servers in the future because of how similar to coc it is.

I think the future hold something similar for debug adapter protocols if I'm not mistaken and a nvim-dapconfig would complement nvim-dap and DAPInstall.nvim in the way nvim-lspconfig complements the native lsp client and nvim-lsp-installer in the overall setup.

From what I've seen, for debugging most people even those who use neovim still recommend using an IDE.

Potential existing implementations: None

*Potential pitfalls:* Handling of language specific extensions, https://github.com/mfussenegger/nvim-dap-python, https://github.com/mfussenegger/nvim-jdtls though I don't know if it should or shouldn't be in the scope of this plugin.

[mfussenegger]

I'd actually advice against doing this for a couple of reasons.

There are mostly two types of adapters. Those who launch via a command call and communicate via stdio and those who require a more sophisticated setup.

The former currently require something like dap.adapters.xy = { type = 'executable', cmd = '/path/to/myadapter' } to setup. I consider this mostly user configuration because the path may be system specific. I don't think a dedicated configuration plugin is warranted for this type, because chances are that people want to configure the path anyway and then you hardly saved anything. Chances are it complicates things.

The second type is more complicated (like go via delve) and for those I consider them more like application logic, not configuration. Ideally language specific extensions like nvim-jdtls, nvim-dap-python or nvim-dap-go take care of those. As you mention in the potential pitfall, there would be friction between those and the generic dapconfig plugin and people may have a worse user experience using one vs. the other. I recommend using language specific extensions over a generic dapconfig/dapinstall solution, because they'll usually lead to a better user experience by also providing more language specific functionality (like debugging tests or even selected code). And chances are they're better maintained because the maintainers know the language well.

The other part is the debug configuration for your application (:h dap-configuration). Despite the nvim-dap wiki recommending some general-purpose configurations, they are intended to be project specific, not global. For that reason nvim-dap also includes support to read .vscode/launch.json files. These can be checked in with the project and you can share them with vscode users to some degree.

Some users will want to run their application in docker containers, others on remote machines, others locally. Paths will be different, options will be different. In short, if you put all that in a single dapconfig project, you end up with a huge permutation of options that users could want. I wouldn't open up this door. Even vscode or an IDE like IntelliJ doesn't include default configurations. What they do instead is making it easy to create those configurations. IntelliJ has a configuration UI/wizard. Some language specific vscode extensions include templates to create launch.json files and you get auto-completion for the properties within a launch.json file.

[punowo]

@mfussenegger Thank you for the explanation. I wasn't aware of the whole landscape as I've only tried to setup nvim-dap once for a single language.

[andmis]

Related: I think that grouping things under the protocol (lsp-config, dap-config) is not really right -- you want to group things by language (python-ide.nvim, lua-ide.nvim, ...). If DAP becomes the standard protocol for debugging in Neovim (and more generally) then hopefully DAP can get merged into Neovim code, and then something like python-ide.nvim can provide LSP, DAP, TS, etc., configuration for working with Python projects, etc.

So IMO it makes sense to not create a dap-config.

[mfussenegger]

I think that grouping things under the protocol (lsp-config, dap-config) is not really right -- you want to group things by language (python-ide.nvim, lua-ide.nvim, ...)

This would also have some downsides. For some languages there are multiple language servers and multiple debug adapters. A good example is python. debugpy is independent of a language server and can be used with either pyright, jedi-language-server or any of the others.

Creating separate plugins around those has the advantage that users can compose them depending on their preference. If you create a nvim-python plugin that supports pyright and debugpy, you may lock out users who want to use debugpy and jedi-language-server.

Similar situation with C/C++, where there are three different debug adapters, all independent of a language server.

On the other hand, there are cases where there is a tight coupling between a language server and a debug adapter. Eclipse.jdt.ls and java-debug is an example. There it makes more sense to have a single plugin that takes care of both (like nvim-jdtls does). And because there are also other language servers for java, not taking up nvim-java also kinda makes sense.

[andmis]

Yes. Having one Neovim plugin per DAP adapter and one Neovim plugin per language server sounds perfectly fine in principle -- the main disadvantage being that it's not as easy for plugin authors to make a very nice interop/IDE experience.

My main point is that having one plugin manage all DAP adapter configs for all languages for all of Neovim is not (IMO) the right design. I am a bit more agnostic about whether it makes sense to have one plugin per adapter and one per language server, or one plugin per language which is opinionated on choice of adapter and language server, or one plugin per language which supports several adapters and language servers.

If I had to guess, I would guess that the winner will be one of the last two options. The reason is that many users like batteries-included experiences, and a high-quality holistic plugin for a language can be created by a maintainer who gets excited about making a great IDE-like experience under Neovim for a particular language -- and it makes sense not to take on dependencies in this case as long as the core Neovim capabilities (LSP, TS, and hopefully soon DAP) are good enough that you don't need plugins to work with them.

(Of course nobody can dictate what kinds of plugins get written, this is more a question of what kind of future we should aim for in the design of the core capabilities supporting the plugin ecosystem.)