Revert "fix: support overwrite when merge config. (#1394)"

[Jint-lzxy]

This reverts commit 7056741.

Sorry for the noise but I'm a lil confused about this new option...? Like idk if the performance difference between these two is even that big, and maybe it's not actually working as expected?

[ayamir]

overwrite option is the only solution to delete pre-defined something, like I want to define edgy.nvim left region with NeoTree rather than NvimTree. Otherwise I need to use function to repeat lots of content the same with defaults.

[Jint-lzxy]

overwrite option is the only solution to delete pre-defined something

But I think this might break some users' expectations of the loader right 🤔 Also think I mentioned vim.NIL elsewhere too, it's like a user object so maybe we can use that to signal "erasure" of the field instead?

[ayamir]

Marking a option as nil is not enough, overwrite is an irreplaceable way to acheive delete and re-define.

[Jint-lzxy]

Marking a option as nil is not enough, overwrite is an irreplaceable way to acheive delete and re-define.

😭 srry if I wasn't super clear earlier! What I meant was we could let users pass vim.NIL inside the override table. Consider :h vim.NIL:

vim.NIL                                                              *vim.NIL*
    Special value representing NIL in |RPC| and |v:null| in Vimscript
    conversion, and similar cases. Lua `nil` cannot be used as part of a Lua
    table representing a Dictionary or Array, because it is treated as
    missing: `{"foo", nil}` is the same as `{"foo"}`.

To break it down, imagine the original table looks like this:

local orig = {
	top = {
		middle = {
			opt = "OKAY SOME OPTIONS",
			whatever = "BLA"
		}
	}
}

And the user's override is like this:

local override = {
	top = {
		middle = vim.NIL,
	},
}

Now, when we call our tbl_recursive_merge, here's what Neovim gives back:

{
  top = { 
    middle = vim.NIL 
  }
}

Then all we need to do is strip out the vim.NIL values in the recursive merge function and we're good to go! Also I've seen this (along with v:null) in tons of plugins, so I'd say it's a pretty "standard" approach and way more systematic. On top of that the main reason why I want to revert this first is "what's the point of setting overwrite=true just for this plugin?" I feel like our users' mileage might vary (possibly by a lot) otherwise.

[ayamir]

😭 srry if I wasn't super clear earlier! What I meant was we could let users pass vim.NIL inside the override table.

My real motivation for introducing this change is NOT to make a part of default configuration be nil, but to use the user's configuration to replace the part of default configuration. For this example, left option is exclusive for different configuration (nvim-tree or other file tree like neo-tree). If the default configuration for nvim-tree is not erased, the left part of edgy will show two file tree like this:

On top of that the main reason why I want to revert this first is "what's the point of setting overwrite=true just for this plugin?" I feel like our users' mileage might vary (possibly by a lot) otherwise.

The reason why I introduce it by adding a parameter to tbl_recursive_merge is whether overwrite or not is clearly for one plugin like the layout option of edgy.nvim.

Of course, the replace function can be impl by using return a function to achieve this, but it needs lots of redundant code.

[ayamir]

This option is useful for search.nvim too.

[Jint-lzxy]

My real motivation for introducing this change is NOT to make a part of default configuration be nil, but to use the user's configuration to replace the part of default configuration.

oh lol my bad I think I got what u meant now, srry for the confusion! I think passing a function as the value for that key should do the trick right? since it's our first branch it should def be respected

[ayamir]

I think passing a function as the value for that key should do the trick right? since it's our first branch it should def be respected

It's OK.