Highlight "link" not honored

[petobens]

Hi, If I have a setup like:

local onedarkpro = require('onedarkpro')

local p = {
    fg = '#abb2bf',
    pmenu = '#333841',
}

onedarkpro.setup({
    theme = 'onedark',
    colors = p,
    hlgroups = {
        NormalFloat = { link = 'Pmenu' },
        Pmenu = { fg = p.fg, bg = p.pmenu },
    },
})

Then the NormalFloat "link" is not respected and defaults to whatever onedarkpro default is. In order for it to work I need to rewrite it as:

NormalFloat = { fg = p.fg, bg = p.pmenu },

Is this a bug or a feature? Thanks in advance.

[olimorris]

If I recall, the highlight group needs to be set before the link to it is called. More a Vim quirk than a design

[olimorris]

@petobens any luck with changing the order of your custom highlight groups?

[petobens]

Nope, it still uses the default value rather than the one specified in my config.

[olimorris]

Nope, it still uses the default value rather than the one specified in my config.

I'll take a look tonight

[olimorris]

I wonder if something else is overwriting your highlight groups...

If I have the following config:

  local ok, onedarkpro = pcall(load, "onedarkpro")

  local p = {
    fg = "#FF0000", -- red
    pmenu = "#00FF00", -- green
  }

  onedarkpro.setup({
    theme = "onedark",
    colors = p,
    hlgroups = {
      ModeMsg = { link = "Pmenu" },
      Pmenu = { fg = p.fg, bg = p.pmenu },
    },
  })
  onedarkpro.load()

Then this is what I get:

If I run hi ModeMsg I see:

If I run hi Pmenu I see:

[petobens]

Hi @olimorris sorry for the terriblly long delay. Can you please try my config: https://github.com/petobens/dotfiles/blob/nvim-lua/nvim/lua/plugin-config/onedark_config.lua#L62

Basically with the following line

NormalFloat = { fg = p.fg, bg = p.pmenu },

I correctly get when running verbose hi NormalFloat:

:verbose hi NormalFloat
NormalFloat    xxx guifg=#abb2bf guibg=#333841
        Last set from Lua

Whereas if I change that line to

NormalFloat = { link = 'Pmenu' },

then I get:

:verbose hi NormalFloat
NormalFloat    xxx guibg=#1f2127
        Last set from Lua

Any pointers are appreciated. Once again sorry for the late replay/lack of follow through.

[olimorris]

I wonder if that's because you're redefining Pmenu after NormalFloat? What happens if you swap them around?

[petobens]

I wonder if that's because you're redefining Pmenu after NormalFloat? What happens if you swap them around?

Same behavior. Weren't you able to reproduce it with my config? I believe that somehow user configs are being overriden by global ones? Thanks btw for all the patience and help.

[olimorris]

I haven't tried with your config; it's a hella lot of work to debug someones config 😉 .I use a link in my config and it works just fine, as does the test I've added to the repo; although appreciate I don't use as many links as yourself. A couple of suggestions:

1. Follow the guide in this issue, and add your onedarkpro config to the minimal.lua file. You can then run a command which opens Neovim with only Packer, Treesitter and onedarkpro without messing up your original config.

2. Can you pair the onedark_config.lua file to as few lines as possible which show the issue? Then I can dig in and try and understand.

I'd say most issues in this repo are due to plugins overwriting highlight groups that the theme applies. My hunch is that is what is happening in your case hence the recommendation to pair back your config to a minimal one.

[petobens]

Great! I'll check over the weekend and try to cook up a minimal example.

[petobens]

Using the following minimal.lua file:

local fn = vim.fn

-- Ignore default config and plugins and define new dirs
local test_dir = '/tmp/nvim-minimal'
vim.opt.runtimepath:remove(fn.expand('~/.config/nvim'))
vim.opt.packpath:remove(fn.expand('~/.local/share/nvim/site'))
vim.opt.runtimepath:append(fn.expand(test_dir))
vim.opt.packpath:append(fn.expand(test_dir))

-- Install packer
local install_path = test_dir .. '/pack/packer/start/packer.nvim'
if fn.empty(fn.glob(install_path)) > 0 then
    packer_bootstrap = fn.system({
        'git',
        'clone',
        '--depth',
        '1',
        'https://github.com/wbthomason/packer.nvim',
        install_path,
    })
end

-- Setup packer
local packer = require('packer')
packer.init({
    package_root = test_dir .. '/pack',
    compile_path = test_dir .. '/plugin/packer_compiled.lua',
})
packer.startup(function(use)
    -- Packer can manage itself
    use('wbthomason/packer.nvim')

    -- Plugins
    use({ 'nvim-treesitter/nvim-treesitter', run = ':TSUpdate' })
    use('olimorris/onedarkpro.nvim')

    -- Auto install plugins
    if packer_bootstrap then
        packer.sync()
    end
end)

-- Plugin setup
local ok, treesitter = pcall(require, 'nvim-treesitter.configs')
if ok then
    treesitter.setup({
        highlight = {
            enable = true,
        },
        ensure_installed = {
            'lua',
        },
    })
end

local ok, onedarkpro = pcall(require, 'onedarkpro')
if ok then
    local palette = {
        fg = '#abb2bf',
        pmenu = '#333841',
    }
    local p = palette
    onedarkpro.setup({
        theme = 'onedark',
        colors = palette,
        hlgroups = {
            Pmenu = { fg = p.fg, bg = p.pmenu },
            NormalFloat = { link = 'Pmenu' },
            -- NormalFloat = { fg = p.fg, bg = p.pmenu },
        },
    })

    onedarkpro.load()
end

If I run :hi NormalFloat I get:

NormalFloat    xxx guibg=#22252c

Instead of the desired:

NormalFloat    xxx guifg=#abb2bf guibg=#333841

Please let me know if you can reproduce it now. And thanks once again for the help and patience.

[olimorris]

Thanks so much for the above. Yep I can confirm that I can recreate it too.

As mentioned before I think it's because of the ordering of the highlight groups in the theme.lua file. To solve it, I think I should apply all link groups at the end of the highlight creation process. I'm working on a big refactor over the next couple of weeks so will try and fix it as part of that.

[petobens]

Great!

[olimorris]

Hey @petobens. I believe this issue has been solved in the current rewrite of the plugin over on the develop branch. Would you mind testing out that branch and confirming if it's solved the issue?

[petobens]

Sure. I'll check it out over the weekend.

[petobens]

Yep thanks!