Setup function makes overriding highlights inconsistent

[akinsho]

Hi @NTBBloodbath 👋🏿 ,

recently I noticed a setup function was added which is nice but adding it seems to make overriding highlights with my custom highlights work inconsistently. Basically my setup is that on the Colorscheme autocommand I call a custom highlight function which I have always had regardless of the colorscheme there are just certain highlights that I want a certain way no matter what colorscheme I use.

Anyway I think that since the setup function also loads the colorschemes highlights it can end up changing the highlights after the colorscheme has already loaded so it happens after the autocommand and my highlight overrides are ignored.

I'm not sure why specifically the plugin needs to load the colorscheme again after setup but am wondering if highlighting by this colorscheme can be restricted to that event otherwise it's impossible to consistently override the colorscheme's highlights.

Does this make sense?

[saifulapm]

Hi.. The setup function don’t change colorscheme that’s why your ColorScheme autocommand not triggered. If you use setup function, you can apply your highlights directly without autocommand.

[akinsho]

@saifulapm I actually meant the require'doom-one'.setup{...} function not the packer setup function. The doom one one actually loads the colorscheme after setup is called which is why I'm experiencing the issue I described, in hindsight maybe it should also call doautocmd Colorscheme since it is manually applying highlights but not giving the rest of nvim a heads up that that is happening

[NTBBloodbath]

Hi akinsho, I'm really sorry per the late reply.

I don't really know how to bypass this, maybe I should refact how doom-one is structured so this shouldn't make issues. Maybe structuring it like folke's tokyonight will help (talking about how tokyonight loads stuff).

I'll do some testing in a separated branch this week, I'll let you know when it's done for you to test it, and sorry again for the delay!

[akinsho]

@NTBBloodbath so I can't speak to general plugin structure but this particular situation I think can maybe be resolved by triggering a colorscheme autocommand manually after calling load colorscheme when the setup function is called.

https://github.com/NTBBloodbath/doom-one.nvim/blob/3826c27fc2415c998cea6b4f85a347ada52a43e5/lua/doom-one/init.lua#L21-L24

In the lines above the users config is read and then the colorscheme is reloaded, now I don't know if this has to be like this or should be refactored but because the plugin is basically re-applying all of it's highlights after the colorscheme autocommand it removes a user's overrides. This can be fixed by telling vim after load_colorscheme is called that highlights have changed again.

so

-- after the load_colorscheme call in line 24
vim.cmd('doautocmd Colorscheme doom-one')

I think this would fix the issue although I think it's kind of a problem that the highlights are being loaded twice so the startup time will be slower.

[NTBBloodbath]

Hmm yeah this could solve the issue at the moment.

And yes, doom-one source code should be refactored since we shouldn't load colorscheme stuff twice because it has a ton of disadvantages. We could try adding this patch at the moment and then start the refactoring :thinking:

[NTBBloodbath]

Hey akin,

It's been a really long time, hope you're doing well. It seems like I did finally stopped procrastinating with other projects to procrastinate with this one and did a rewrite (still need to add missing plugins integrations) haha.

It does go back to the good ol' classic Neovim global variables to setup colorscheme settings, not too much breaking changes at all as I did try to keep the same option names from setup function, and also improves performance a bit (at least from my tests).

That said, please let me know if you can give rewrite branch a shot so we can close this issue once I merge it.

Cheers

[akinsho]

Hi @NTBBloodbath tried it out and seems to work great 👍🏿 thanks

[NTBBloodbath]

Cool thanks, merged rewrite branch!