dap-view configuration at adapter config level

[catgoose]

Instead of creating config keys for different adapters and since you can get an adapter's config from dap.session(), you could instruct the user to create dap_view config key in their adapter config:

    dap.configurations.go = {
      {
        type = "go",
        name = "Debug main.go",
        request = "launch",
        showLog = true,
        program = "${workspaceFolder}/main.go",
        dlvToolPath = dlvToolPath,
        dap_view = {
          terminal = {
            enabled = false,
          },
        },
      },
}

Then you don't have to update dap-view setup opts, only create the logic in the plugin and update readme about what dap_view.

This also allows the user to have finer grain control over dap-view. For example if I have two delve configurations, one that is for a web application and the other TUI:

    dap.configurations.go = {
      {
        type = "go",
        name = "Debug main.go Webserver",
        request = "launch",
        showLog = true,
        program = "${workspaceFolder}/main.go",
        dlvToolPath = dlvToolPath,
        dap_view = {
          terminal = {
            enabled = false,
          },
        },
      },
      {
        type = "go",
        name = "Debug main.go TUI",
        request = "launch",
        showLog = true,
        program = "${workspaceFolder}/main.go",
        dlvToolPath = dlvToolPath,
        dap_view = {
          terminal = {
            enabled = true,
          },
        },
      },
}

I'm sure we could provide callbacks in the adapter configuration as well.

Personally I like this sort of inversion pattern because it requires the least amount of complexity at the plugin level and provides the user with the most flexibility.

[igorlfs]

I'm not entirely against this idea, but I don't think there's a strong use case. Mostly because:

1. I don't see it being used for something other than the enabling (or disabling) the terminal. Perhaps someone might wanna disable the exceptions view if the adapter doesn't support it?
2. Assuming that the terminal is the only thing that matters, there are other ways to achieve a "project-local" configuration, without meddling with the session configuration. For instance, using a .lazy.lua (or .nvim.lua) to override the default configuration (once feat!: allow disabling the terminal adapters for selected adapters #10 is merged).

[catgoose]

nice I didn't know about .lazy.lua