Closed scottmckendry closed 4 months ago
Actually the names are Markview_something
.
The add_hl
function automatically adds the Markview_
prefix.
Also, that's not why the highlight_groups
option exists.
It's there for when you are happy with the defaults(or don't want them to be dependent on the color scheme).
In my case, I have made a simple plugin that sets them to whatever I chose for the current color scheme. So that I don't have to set them up for each color scheme.
Actually the names are
Markview_something
.The
add_hl
function automatically adds theMarkview_
prefix.
Ahhh, yes! I can see that now 🙂 Ignore my ramblings then. I can see all the highlight groups are prefixed as you've pointed out:
@OXY2DEV that would be nice if combined with the marview plugin itself,wouldn't it?
I have edited the highlight group as example Markview_red
through my color scheme. But they doesn't change the appearance at all, default one is still in use. Why that?
@OXY2DEV that would be nice if combined with the marview plugin itself,wouldn't it?
I have edited the highlight group as example
Markview_red
through my color scheme. But they doesn't change the appearance at all, default one is still in use. Why that?
Because add_hl()
runs when neovim starts(in your case after your color scheme).
Just set highlight_grops = false
(basically anything that's not a list) and it should work as intended.
Thanks @OXY2DEV, I think I might need to reopen this one since I've not been able to get these highlight groups working at all.
My configuration looks like this:
return {
"OXY2DEV/markview.nvim",
ft = "markdown",
dependencies = {
"nvim-tree/nvim-web-devicons",
},
config = function()
require("markview").setup({
highlight_groups = false,
})
end,
}
But I still can't override the defaults.
Thanks @OXY2DEV, I think I might need to reopen this one since I've not been able to get these highlight groups working at all.
My configuration looks like this:
return { "OXY2DEV/markview.nvim", ft = "markdown", dependencies = { "nvim-tree/nvim-web-devicons", }, config = function() require("markview").setup({ highlight_groups = false, }) end, }
But I still can't override the defaults.
Yeah, I just realized it doesn't work. My bad.
You will probably have to wait for me to change how the highlights are applied.
No worries @OXY2DEV! It would be good to be able to mix and match colorscheme highlights with the defaults. Rather than it being an on/off thing in the config. Most plugins support overrides in such a way that the user's config doesn't have to be modified at all.
I think the reason this particular option isn't working is because this block inside markview.lua
executes before setup()
is called:
-- line 544-546
if vim.islist(markview.configuration.highlight_groups) then
markview.add_hls(markview.configuration.highlight_groups);
end
This is before the config includes any user options. But again, all highlight groups should be created regardless if the user wants to use them or not.
It would be good to remove this option altogether, and allow users to override individual groups either through a colorsheme or manually with something like :hi Markview_red guifg=#ff0000
.
I think the reason this particular option isn't working is because this block inside
markview.lua
executes beforesetup()
is called:-- line 544-546 if vim.islist(markview.configuration.highlight_groups) then markview.add_hls(markview.configuration.highlight_groups); end
This is before the config includes any user options. But again, all highlight groups should be created regardless if the user wants to use them or not.
Yes, that's the root of the issue.
It will be fixed with all the other color related things in the next update
I would also suggest updating the markview.add_hls
function to append default = true
to the highlight group value. This will preserve any predefined groups:
markview.add_hls = function(usr_hls)
local hl_list = usr_hls or renderer.hls
for _, tbl in ipairs(hl_list) do
tbl.value.default = true
vim.api.nvim_set_hl(0, "Markview_" .. tbl.group_name, tbl.value)
end
end
I've tested this locally and it works with the highlight group definitions in my colorscheme - so no changes required to the default options in markview's setup()
. This will make it a lot easier for other colorshemes to add support as this plugin (inevitably) grows in popularity 🙂
I would also suggest updating the
markview.add_hls
function to appenddefault = true
to the highlight group value. This will preserve any predefined groups:markview.add_hls = function(usr_hls) local hl_list = usr_hls or renderer.hls for _, tbl in ipairs(hl_list) do tbl.value.default = true vim.api.nvim_set_hl(0, "Markview_" .. tbl.group_name, tbl.value) end end
I've tested this locally and it works with the highlight group definitions in my colorscheme - so no changes required to the default options in markview's
setup()
. This will make it a lot easier for other colorshemes to add support as this plugin (inevitably) grows in popularity 🙂
I was actually going to use the default highlight groups mentioned in highlight-default
.
For your colorscheme's case it looks like this.
Of course, this doesn't work with some of the older colorscheme's(as they don't define all of the necessary highlight groups). But you can always switch them out with something else.
This is excellent! I've checked out the dev
branch with your changes and it looks great! Except when I enable transparency the backgrounds look off - I think this is because bg
is being used in the mix()
function to calculate the highlight when its value is NONE
. This may be an issue for other themes too:
I'm not sure what the best solution is for this. But I'll leave that with you 😉
It appears that overrides are working now too! Great stuff!
@scottmckendry It appears that you can't have semi-transparent colors in neovim(at least not for normal texts).
So, I can't really find a clear way to make the background color look nice for all colorschemes.
And it doesn't help that I can't get the default background color when the transparency is used.
Final implementation that was recently merged into main looks good. Thanks for working on this @OXY2DEV.
Would you be open to converting highlight groups from snake_case
to PascalCase
? It will effectively be a breaking change, so the earlier you do it the better.
The reason I ask is because this is the only plugin I've come across so far that uses underscores in highlight group names. This is also consistent across all of the default highlight groups in Neovim. Such as StorageClass
and SpecialChar
.
Also, for my own selfish reasons, I have regex that looks for PascalCase highlight groups and attempts to apply the highlights to the text, This falls apart with the snake_case naming convention since the code was written with the assumption that these are lua variables.
Would you be open to converting highlight groups from
snake_case
toPascalCase
? It will effectively be a breaking change, so the earlier you do it the better.
I honestly don't care about what is used for naming as long it doesn't affect readablity
.
The reason I ask is because this is the only plugin I've come across so far that uses underscores in highlight group names. This is also consistent across all of the default highlight groups in Neovim. Such as
StorageClass
andSpecialChar
.
Seems like a valid reason.
Also, for my own selfish reasons, I have regex that looks for PascalCase highlight groups and attempts to apply the highlights to the text, This falls apart with the snake_case naming convention since the code was written with the assumption that these are lua variables.
Is it for coloring highlight group
names?
Anyway, I probably will switch the naming of highlight groups in the next commit.
So, I was looking at other highlight names and realized that there are highlight groups that don't use PascalCase.
Plus, catppuccin seem to use camelCase which is strange.
Hello @OXY2DEV!
First off, this plugin is very impressive. What you've been able to achieve in a short space of time (and on a phone!?) is excellent.
I want to add native support for the plugin directly to my colorscheme (cyberdream.nvim) and notice that the highlight group naming convention seems a bit... off?
Names like
green_fg
andgradient_4
are great for local variables, but for highlight groups that all share a single namespace it doesn't really make a whole lot of sense.What I'm suggesting it to adapt the existing highlight groups with a prefix. For example:
green_fg
would becomeMarkviewFgGreen
gradient_4
would becomeMarkviewGradient4
This makes identifying groups that belong to the plugin amongst the hundreds of others much easier.
If you want to see more examples of naming conventions, I would suggest checking out a few of the resources below:
If you have any questions around this, please let me know!