[Feature Request] set dap.defaults options about nixvim

[MattSturgeon]

I'd appreciate a pointer on how post-setup lua code tends to be run for plugins that have setup for that.

Generally speaking, I think we normally do pre/post setup code by calling setup manually.

Plugins implemented with mkNeovimPlugin tend to automatically generate code to call setup, but mkNeovimPlugin could easily be extended to accept pre/postExtraConfigLua arguments if needed.

In a normal neovim setting, those should be set after calling setup(). Which I think is the reason for why [it] does not work in my nix configuration

I don't think we ever call a DAP setup function, however we do do some "setup config" by adding lines to plugins.dap.extensionConfigLua (internal option) and here:

nixvim/plugins/dap/default.nix

Lines 86 to 99 in 40598fc

	extraConfigLua =
	(optionalString (cfg.adapters != null) ''
	require("dap").adapters = ${helpers.toLuaObject options.adapters}
	'')
	+ (optionalString (options.configurations != null) ''
	require("dap").configurations = ${helpers.toLuaObject options.configurations}
	'')
	+ (optionalString (cfg.signs != null) ''
	local __dap_signs = ${helpers.toLuaObject options.signs}
	for sign_name, sign in pairs(__dap_signs) do
	vim.fn.sign_define(sign_name, sign)
	end
	'')
	+ cfg.extensionConfigLua;

Maybe someone more familiar with our DAP module could help better here.

Maybe, you'd even want to generalize by always making it so that in nixvim, options that aren't accepted by the setup are then attempted to be added to the plugin's table.

I'm not sure what you mean by this, since the plugin settings table is what is passed to the setup function.

As for options unknown to nixvim, these are included in the table passed to setup (as-per RFC42) for any module that has been written/refactored recently.

[JJJHolscher]

oops, sorry for that "bug" label, that's inaccurate

[JJJHolscher]

The chances of me implementing this myself dropped since I'm more fine interspersing lua code throughout my nixvim config.
Even though this feature is too my knowledge, still unimplemented, I'm fine with closing it.

[MattSturgeon]

Even though this feature is too my knowledge, still unimplemented, I'm fine with closing it.

If you think others may find it useful, you're welcome to leave it open and "unsubscribe" if you're not interested in notificatione. Otherwise if you think it has no value, closing is fine.