๐ Bug: Highlight is set to one color
snikoletopoulos opened this issue ยท 9 comments
Before reporting:
- Ensure that the issue is reproducable on the main branch.
- Ensure that there isn't an issue on this(either open or closed).
Problem:
When using headers, either with #
, ===
or ---
the color is always red.
Same for block quotes.
When viewing highlights with Telescope they are set to this red color.

It was working 2 days ago.
Let me know if you need more info or if you have any suggestions to debug it if it is my own config.
Steps to reproduce the issue:
Open a markdown file with headings
Expected behavior:
No response
Neovim version:
0.10.1
Unless the colorscheme you use explicitly sets the @markup.heading
or @markup.heading.n.markdown
to a single color this wouldn't happen.
A bit of context,
Before the plugin wouldn't directly use @markup.heading
(instead the Diagnostics highlight groups were used). This came with the flaw that the previews & the tree-sitter highlights wouldn't match in some colorschemes. This is the reason this was changed.
I am experiencing the same issue with Catppuccin. In insert
mode, the colors display correctly with tree-sitter, but in normal
mode, is entirely white.
I am experiencing the same issue with Catppuccin. In
insert
mode, the colors display correctly with tree-sitter, but innormal
mode, is entirely white.
What does :hi @markup.heading.1.markdown
say?
Also, you should check
markdownH1
&@markup.heading
highlight groups since their colors are used.
Also, a screenshot of the issue would be great!
Setup:
{
"OXY2DEV/markview.nvim",
dependencies = {
"nvim-treesitter/nvim-treesitter",
"nvim-tree/nvim-web-devicons",
},
config = function()
local presets = require("markview.presets")
require("markview").setup({
filetypes = { "markdown", "quarto", "rmd", "Avante" },
checkboxes = presets.checkboxes.nerd,
headings = presets.headings.marker,
})
end,
}
Normal mode:
Insert mode:
I can't reproduce the issue. I am also using catppuccin.
@rachartier maybe try creating a minimum repro.
Create a repro.lua
file and paste this in it.
vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()
require("lazy.minit").repro({
spec = {
{
"nvim-treesitter/nvim-treesitter",
opts = {
ensure_installed = { "markdown", "markdown_inline" }
}
},
{
"OXY2DEV/markview.nvim",
lazy = false
},
{
"catppuccin/nvim",
priority = 1000
}
}
})
vim.cmd.colorscheme("catppuccin");
Then run,
nvim -u repro.lua test.md
And see if the issue persists.
Thanks, I've found the issue. Maybe @snikoletopoulos does have the same issue: I was using lazy loading on catppuccin/nvim
with event = VimEnter
and by removing it, everything is now working perfectly.
Thank you !
I'm having a similar issue:
I'm using onedark and I wanted to use custom colors for H3, H4, H5.
In my usual config, the headings use the treesitter highlighting, so I overrid the treesitter @markup.heading.4... hl-groups
But markview inherited the colors from the markdownH4,... highlight group, so it rendered them the old colors.
Maybe I'm doing something wrong, but I managed to reproduce it with this config:
repro.lua:
vim.env.LAZY_STDPATH = ".repro"
load(vim.fn.system("curl -s https://raw.githubusercontent.com/folke/lazy.nvim/main/bootstrap.lua"))()
require("lazy.minit").repro({
spec = {
{
"nvim-treesitter/nvim-treesitter",
build = ":TSUpdate",
config = function()
local configs = require("nvim-treesitter.configs")
local opts = {
ensure_installed = { "markdown" },
highlight = {
enable = true,
},
}
configs.setup(opts)
end
},
{
"OXY2DEV/markview.nvim",
lazy = false
},
{
"navarasu/onedark.nvim",
lazy = false,
config = function()
require('onedark').setup {
style = 'warmer',
highlights = {
-- ["markdownH4"] = { fg = "$green" },
["@markup.heading.4.markdown"] = { fg = "$green" },
-- ["markdownH5"] = { fg = "$blue" },
["@markup.heading.5.markdown"] = { fg = "$blue" },
-- ["markdownH6"] = { fg = "$dark_cyan" },
["@markup.heading.6.markdown"] = { fg = "$dark_cyan" },
},
}
end
},
}
})
vim.cmd.colorscheme("onedark");
Sorry if this would have been better as a new issue @OXY2DEV