[Question] Does built-in linking take precedence over the values set in the setup function?

[anthony-S93]

@olimorris

I did an experiment by setting:

highlights = {
    ["@keyword"] = { fg = "${purple}", style = "bold" },
}
-- Set "@keyword" while leaving the "Keyword" highlight group in its default value 

The :hi @keyword command showed something surprising, at least to me.

I expected the @keyword highlight group to be overridden by the setting in the setup function, but that appears to not be the case. The highlight group was still linked to the Keyword highlight group (which I assume was done internally in the plugin). Not even un-setting the highlight group @keyword = {} has any effect, which seems a bit counterintuitive.

The settings in the setup function will only apply if the group isn't internally (hard coded?) linked to other groups. E.g: @conditional

highlights = {
    ["@conditional"] = {fg = "${purple}", style = "bold"}, -- this one works
}

[olimorris]

Yep you're right. I can confirm this too. It stems from this PR which I merged a few weeks back.

The idea behind the PR was to add the ability to add italic = true, bold = true styling options and to extend existing highlight groups. In hindsight, most users want to simply overwrite the default. Will transfer this to an issue and publish a fix.

Thanks for raising.

[maxmx03]

I apologize for any confusion caused.Here my suggestion for this issue:

We can use the values of the original highlight group and apply them to the linked highlight group along with the user's configuration. This way, we would preserve the configuration set by the colorscheme while also incorporating the user's configuration.

compile.lua

local function get_hl(...)
  local group = vim.api.nvim_get_hl(...)

  if group.link then
    return get_hl(0, { name = group.link, link = true })
  end

  return group
end

config_spec.vim

['@keyword'] = { fg = "${purple}", style = "bold" },

config_spec.lua

it("should be able to override linked highlight group", function()
    local output = vim.api.nvim_get_hl(0, { name = "@keyword" })
                                                                   
    assert.is_nil(output.link)
    assert.are.same("#d55fde", hex(output.fg))
    assert.is_true(output.bold)
end)

cc: @olimorris

[olimorris]

With hindsight, my preference is for users to explictly declare they wish to extend a highlight group.

If it comes to debugging their config and wondering why something has changed, I think this makes it way easier.

[anthony-S93]

@maxmx03 Thanks for the response.

I also discovered that for some highlight groups like @include.python, linking in the setup function doesn't work but setting the values directly does. For example, suppose I have the following in my setup file:

["@include"] = { fg = "${purple}", style = "bold" },
["@include.python"] = { link = "@include" }, --this does not work

Which results in:

But if we forego the link and set the values directly, it works. As in:

["@include"] = { fg = "${purple}", style = "bold" },
["@include.python"] = { fg = "${purple}", style = "bold" }, --this works as expected

This is a bit counter-intuitive, to be honest. So far, there doesn't seem to be a uniform behavior that applies for these highlights.

[maxmx03]

@anthony-S93 Strange, the link should work because if you look at the source code, you'll see a conditional statement that should handle the linking of one highlight group to another.

it works for me

[anthony-S93]

@maxmx03

Thanks for the taking the time to check it. Yes, it's working right now. It wasn't working when I tested it. I should've updated this comment earlier. My bad.