Skip to content

Commit

Permalink
Move on_config hooks from providers to listeners
Browse files Browse the repository at this point in the history
Fits a bit better and there may be other client generated events in the
future.
  • Loading branch information
mfussenegger committed Jun 1, 2024
1 parent 1f609cb commit eebde2c
Show file tree
Hide file tree
Showing 2 changed files with 55 additions and 40 deletions.
81 changes: 48 additions & 33 deletions doc/dap.txt
Original file line number Diff line number Diff line change
Expand Up @@ -1241,6 +1241,54 @@ For events, the listeners are called with two arguments:
2. The event payload


==============================================================================
BUILT-IN CLIENT EVENTS *dap-listeners-ext*

In addition to the debug adapter protocol messages, the `dap.listeners` also
provides hooks to listen on and react to synthethic events created by the
client.

Currently there are:

- `dap.listeners.on_config` (See |dap-listeners-on_config|)

==============================================================================
ON_CONFIG EXTENSIONS API *dap-listeners-on_config*


Plugins can pre-process the |dap-configuration| whenever a debug session
starts.

To do so, register a `on_config` hook in the `dap.listeners.on_config` table.

The key for the table is a `plugin-id`. Plugins should use their plugin name.
Do _not_ use the `dap.` namespace. It is reserved for nvim-dap itself.

The value for the table is a function that takes a |dap-configuration| as
parameter and must return a |dap-configuration|.

Before making modifications to the config you should copy it, to ensure you
don't make permanent changes to a configuration stored within
`dap.configrations.<filetype>` via mutations.

Example:
>lua
local dap = require("dap")
dap.listeners.on_config["dummy-noop"] = function(config)
return vim.deepcopy(config)
end
<
To support async operations, the on_config functions are called within a
coroutine.

This functionality should only be used by plugins that implement generic
functionality applicable for all or most configurations.
If you are writing a plugin that already owns an adapter definition, you
should prefer using the `enrich_config` function available in |dap-adapter|.
If you are not owning the adapter definition but the plugin's functionality is
still specific to a limited selection of adapters, please make sure you're not
messing with configurations used with adapters foreign to your plugin.

==============================================================================
PROVIDERS EXTENSIONS API *dap-providers*

Expand Down Expand Up @@ -1291,39 +1339,6 @@ An example:
To support async operations, the config providers functions are called
within a coroutine.

==============================================================================
ON_CONFIG EXTENSIONS API *dap-providers-on_config*

Plugins can pre-process the |dap-configuration| whenever a debug session
starts.

To do so, register a `on_config` hook in the `dap.providers.on_config` table.

The key for the table is a `plugin-id`. Plugins should use their plugin name.
Do _not_ use the `dap.` namespace. It is reserved for nvim-dap itself.

The value for the table is a function that takes a |dap-configuration| as
parameter and must return a |dap-configuration|.

Before making modifications to the config you should copy it, to ensure you
don't make permanent changes to a configuration stored within
`dap.configrations.<filetype>` via mutations.

Example:
>lua
local dap = require("dap")
dap.providers.on_config["dummy-noop"] = function(config)
return vim.deepcopy(config)
end
<
To support async operations, the on_config functions are called within a
coroutine.

This functionality should only be used by plugins that implement generic
functionality applicable for all or most configurations.
For configuration pre-processing that is specific to a individual adapter you
should instead use the `enrich_config` function available in |dap-adapter|.

==============================================================================
UTILS API *dap-utils*

Expand Down
14 changes: 7 additions & 7 deletions lua/dap.lua
Original file line number Diff line number Diff line change
Expand Up @@ -118,14 +118,17 @@ M.listeners = {
rawset(tbl, key, {})
return rawget(tbl, key)
end
});
}),
---@type dap.listeners
after = setmetatable({}, {
__index = function(tbl, key)
rawset(tbl, key, {})
return rawget(tbl, key)
end
});
}),

---@type table<string, fun(config: dap.Configuration):dap.Configuration>
on_config = {}
}


Expand Down Expand Up @@ -268,9 +271,6 @@ M.configurations = {}
local providers = {
---@type table<string, fun(bufnr: integer): dap.Configuration[]>
configs = {},

---@type table<string, fun(config: dap.Configuration):dap.Configuration>
on_config = {},
}
do
local providers_mt = {
Expand Down Expand Up @@ -388,7 +388,7 @@ do
return ret
end

providers.on_config["dap.expand_variable"] = function(config)
M.listeners.on_config["dap.expand_variable"] = function(config)
return vim.tbl_map(expand_config_variables, config)
end
end
Expand Down Expand Up @@ -547,7 +547,7 @@ local function prepare_config(config)
config = config()
assert(config and type(config) == "table", "config metatable __call must return a config table")
end
for _, on_config in pairs(providers.on_config) do
for _, on_config in pairs(M.listeners.on_config) do
config = on_config(config)
end
return config
Expand Down

0 comments on commit eebde2c

Please sign in to comment.