Checklist

• I have searched through the AstroNvim docs
• I have searched through the existing issues of AstroNvim
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

n/a

Operating system/version

n/a

Terminal/GUI

n/a

Describe the bug

I'm trying to write a plugin to add a palette to astrotheme.
I have a lua/astrotheme/paletes/astrobox.lua file in my plugin directory. Running require("astrotheme").load("astrobox") crashes during util.set_palettes when trying to extend my palette with astrotheme.config.palettes.astrobox is nil.
Adding an empty table to the config fixes the issue, but requires a user to change their astrotheme's config when adding a palette plugin.

Steps to Reproduce

1. Copy an existing palette in the "lua/astrotheme/palettes" directory with a new name (for exemple "astronew.lua")
2. Run neovim, try to run :lua require("astrotheme").load("astronew")
3. Observe the error

Expected behavior

The palette is loaded and the theme changes.

Screenshots

No response

Additional Context

The following changes to util.lua fix the issue (I can create a PR):

diff --git a/lua/astrotheme/lib/util.lua b/lua/astrotheme/lib/util.lua
index b8f848b..e4c1a25 100644
--- a/lua/astrotheme/lib/util.lua
+++ b/lua/astrotheme/lib/util.lua
@@ -50,13 +50,13 @@ function M.set_palettes(opts)
   local palette_name = "astrotheme.palettes." .. opts.palette
   if opts.dev then package.loaded[palette_name] = nil end
   local palette = require(palette_name)
-  palette = vim.tbl_deep_extend("force", palette, opts.palettes.global)
-  return vim.tbl_deep_extend("force", palette, opts.palettes[opts.palette])
+  palette = vim.tbl_deep_extend("force", palette, opts.palettes.global or {})
+  return vim.tbl_deep_extend("force", palette, opts.palettes[opts.palette] or {})
 end
 
 function M.set_highlights(opts, highlights, theme)
-  local global_hl = opts.highlights.global
-  local theme_hl = opts.highlights[theme]
+  local global_hl = opts.highlights.global or {}
+  local theme_hl = opts.highlights[theme] or {}
 
   pcall(global_hl.modify_hl_groups, highlights, C)
   pcall(theme_hl.modify_hl_groups, highlights, C)

Thanks a lot for your time on astronvim!

Not sure if this is an issue or intensional, but I believe some of the colors for the terminal are flipped between their normal and bright counterparts. This is the neofetch color block output now:

This is how I believe it should be:

Is your feature related to a problem?

I migrated from VSCode today and, currently, everything is going smoothly, but one thing that is really bothering me is how the default theme doesn't show the "complete" syntax highlighting for Golang, and Golang only, i tested with Java, Lua, HTML and TypeScript and the syntax highlighting worked well with every single one.

Describe the new feature

Basically, it would be cool to make the syntax highlighting integrate better on Go, here goes a comparation between how the syntax highlighting works with Golang and TypeScript, and how much better it works for TypeScript.

Additional context

For additional context, i have the Golang LSP installed on my setup.

When using noice.nvim the cursor is not shown in either astrolight or astrodark but works fine in the other non-astro themes.

astrodark

astrolight

slate

Without lightspeed highlight groups, it makes the plugin look like it's not working. Mainly because the plugin doesn't actually move the cursor while the search is happening, but uses highlight groups to make it look like the cursor is moving. We should get lightspeed highlight groups added to AstroTheme. ~ @mehalter

ORIGINAL ASTRONVIM BUG REPORT

Checklist

• Using a stable version of Neovim (i.e. not neovim nightly)
• :AstroUpdate
• Restarted AstroNvim

Operating system/version

Windows

Terminal/GUI

neovide, conemu, windows native

AstroNvim Health

astronvim: require("astronvim.health").check()

AstroNvim

• INFO: AstroNvim Version: v3.15.6
• INFO: Neovim Version: v0.8.3
• OK: Using stable Neovim >= 0.8.0
• OK: git is installed: Used for core functionality such as updater and plugin management
• OK: explorer is installed: Used for gx mapping for opening files with system opener (Optional)
• WARNING: lazygit is not installed: Used for mappings to pull up git TUI (Optional)
• OK: node is installed: Used for mappings to pull up node REPL (Optional)
• WARNING: gdu is not installed: Used for mappings to pull up disk usage analyzer (Optional)
• WARNING: btm is not installed: Used for mappings to pull up system monitor (Optional)
• OK: python is installed: Used for mappings to pull up python REPL (Optional)

Describe the bug

The cursor (and sometimes a part of the screen) doesn't get updated, when it should.
Only after a subsequent keystroke the cursor jumps into place.

This is most notacable and disturbing, when using lightspeed or leap to jump. See reproduce section.

Steps to Reproduce

The bug is spotted at least in leap/lightspeed/fugitive plugins. It's always a missing refresh or redraw event.

The easiest to reproduce is with lightspeed:

1. Install Astronvim on Windows following the instructions from https://astronvim.com/#%EF%B8%8F-installation
2. Add %HOMEPATH%\AppData\Local\nvim\lua\user\init.lua with

return {
  plugins = {
    {
      "ggandor/lightspeed.nvim",
      lazy = false
    },
  },
}

3. Run Nvim to install all plugs, then reopen nvim
4. Open a new buffer, paste the following two lines of text

test123 test123

5. Place the cursor on the first line. It looks like

▋
test123 test123

6. Now press s12. The cursor should jump to the first 1. But instead, the cursor stays on the first line. It looks like this:

▋
test123 test123s

The s at the end is the shortcut for the second 1. Pressing s you would jump to the second 1.

7. Press i to go into INSERT mode, now the cursor moved to the currect possition.

test|123 test123

Alternativly, you could press z, that on its own has no effect. The cursor will jump to the correct position:

test▋23 test123

Expected behavior

The cursor should always be rendered at its current position.

Screenshots

No response

Additional Context

With fugitive I have some part of the screen, that is not rendered properly. It happend after pressing cc in the :G (status) buffer to commit changes. The commit message buffer is missing the cursor and some ascii-draw characters.

Checklist

• Using a stable version of Neovim (i.e. not neovim nightly)
• :AstroUpdate
• Restarted AstroNvim

Operating system/version

ubuntu20.04

Terminal/GUI

kitty

AstroNvim Health

astronvim: require("astronvim.health").check()

AstroNvim ~

• AstroNvim Version: v3.33.5
• Neovim Version: v0.9.1
• OK Using stable Neovim >= 0.8.0
• OK git is installed: Used for core functionality such as updater and plugin management
• OK xdg-open is installed: Used for gx mapping for opening files with system opener (Optional)
• WARNING lazygit is not installed: Used for mappings to pull up git TUI (Optional)
• OK node is installed: Used for mappings to pull up node REPL (Optional)
• WARNING gdu is not installed: Used for mappings to pull up disk usage analyzer (Optional)
• OK btm is installed: Used for mappings to pull up system monitor (Optional)
• OK python is installed: Used for mappings to pull up python REPL (Optional)

Describe the bug

1. Brackets not highlighted.
2. The highlight color of the same variable is very light, is there a way to modify the background color? As shown in the figure below
   

Steps to Reproduce

1. Brackets not highlighted.
   

Expected behavior

like this

Screenshots

No response

Additional Context

No response

Checklist

• I have searched through the AstroNvim docs
• I have searched through the existing issues of AstroNvim
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

0.9.1

Operating system/version

linux

Terminal/GUI

any

Describe the bug

zsh autosuggestion colors are forced black in a terminal buffer.

Steps to Reproduce

peep the bug repo and steps as follows.

1. docker run -it hacksore/astro-zsh-bug
2. let it cook
3. open nvim
4. let it cook again
5. make a new :terminal
6. in the terminal run zsh
7. write something like brew help
8. write brew

You should see the black text now after brew in the suggestions

Expected behavior

you should have the normal color respected by ZSH_AUTOSUGGEST_HIGHLIGHT_STYLE in my case:

export ZSH_AUTOSUGGEST_HIGHLIGHT_STYLE="fg=8"

Screenshots

what the bug looks like

How it should look

Additional Context

I did some digging and think the cause is astrotheme related as this didn't happen in v1.

When using the nvim-dap-ui plugin it looks like the font color for the variables are not visible.

astrodark

astrolight

It appears that the highlight colors have been removed. Why is this?

:set background=light and vim.opt.background = "light" should work for switching between dark/light themes

If you <leader>gd then try to select something from the diff the text is not legible.

Sorry for noob question, but I don't understand how to properly change background color

Hi,

why is it that when writing git commit messages, or reviewing commits via telescope (in astronvim with astrothem), it shows both added and deleted lines equally blue? Is this intended or is something not working properly for me?

See https://imgur.com/a/NGH8FpU

To make the removed lines appear red and the added lines appear green i had to change colors for the Identifier and Special highlight groups. But I don't understand why.

See https://imgur.com/a/q8ChjKW

Setting DiffAdd and DiffDelete colors seemed to have no effect.

I'd appreciate any input on this.

Also, just wanted to let you know, very nice work on Astronvim and the Astrotheme. I've only recently switched to nvim from vim, and was running a custom setup for a few months, but yours is so much better out of the box. I'm very impressed with the LSP integration, and and the fluidity and responsive of it all. So many good choices were made for this. Thank you.

Checklist

• I have searched through the AstroNvim docs
• I have searched through the existing issues of AstroNvim
• I have searched the existing issues of plugins related to this issue

Neovim version (nvim -v)

0.9.5

Operating system/version

macOS 14

Terminal/GUI

iterm2

Describe the bug

See screenshots below featuring Mason and Telescope: the floating windows blend with the theme's dark background, so it's not too nice to look at, hard to say where one begins and the other ends.

It would be nice to either change backgrounds colors (make the float a different bg color or maybe dim the underlying windows. The issue is worse with Mason because there's no border at all (see screenshots).

Steps to Reproduce

1. Open a float (Telescope or Mason, for example)
2. See it the background is the same and that's is hard to tell it apart from the underlying windows

Expected behavior

I'd like to clearly see it's a floating window

Screenshots

Additional Context

Thank you!

would be great if we have a theme that works with transparency ..
i guess that would be a advantage and a nice usp for our theme :D

Along with the HighlightURL highlight group, AstroNvim also uses some custom Heirline highlight groups we should add. The default definition for the astrodark colorscheme are found here:

https://github.com/AstroNvim/AstroNvim/blob/4f4269d174d85df8b278a6e09d05daeef840df4a/lua/configs/heirline.lua#L24-L37

Checklist

• Using a stable version of Neovim (i.e. not neovim nightly)
• :AstroUpdate
• Restarted AstroNvim

Operating system/version

Arch Linux / 6.5.3-arch1-1

Terminal/GUI

kitty

AstroNvim Health

─────────────────────────────────────────────────────────────────────────────
2 astronvim: require("astronvim.health").check()
3
4 AstroNvim
5 - AstroNvim Version: v3.36.9
6 - Neovim Version: v0.9.2
7 - OK Using stable Neovim >= 0.8.0
8 - OK git is installed: Used for core functionality such as updater and plugin management
9 - OK xdg-open is installed: Used for gx mapping for opening files with system opener (Optional)
10 - WARNING lazygit is not installed: Used for mappings to pull up git TUI (Optional)
11 - OK node is installed: Used for mappings to pull up node REPL (Optional)
12 - WARNING gdu is not installed: Used for mappings to pull up disk usage analyzer (Optional)
13 - WARNING btm is not installed: Used for mappings to pull up system monitor (Optional)
14 - OK python is installed: Used for mappings to pull up python REPL (Optional)
15

Describe the bug

Transparency don't seem to apply.
Also, any changes that are described in the README of https://github.com/AstroNvim/astrotheme under options as well.

~/.config/nvim/lua/init.lua
require("astrotheme").setup({
style={
transparent = true
}
})

Steps to Reproduce

change ~/.config/nvim/lua/init.lua
start nvim

Expected behavior

Transparency applied to the theme.

Screenshots

Additional Context

No response

Highlight group customizations do not persist if the colorscheme is reloaded—or if one switches colorschemes and then back again. Is this expected behavior? For example, the following colorschemes take effect the first time I load astrodark. But if I temporarily switch colorschemes in a session and then switch back, none of these modifications stick. Is this expected behavior? I'm running the latest and greatest version of Astronvim/Astrotheme. Thanks!

        astrodark = {
          modify_hl_groups = function(hl, c)
            hl["@parameter"].italic = true
            hl["Title"].bold = true
            hl["TelescopeResultsTitle"].bold = true
            hl["TelescopeResultsTitle"].italic = true
            hl["TelescopePromptTitle"].bold = true
            hl["TelescopePromptTitle"].italic = true
            hl["TelescopePreviewTitle"].bold = true
            hl["TelescopePreviewTitle"].italic = true
            hl["yamlBlockMappingKey"] = { fg = c.syntax.purple }
            hl["yamlFlowMappingKey"] = { fg = c.syntax.purple }
            hl["@punctuation.bracket"] = { fg = "#898C96" }
            hl["@punctuation.delimiter"] = { fg = "#898C96" }
            hl["Operator"] = { fg = "#898C96" }
            hl["markdownH1"] = { fg = c.ui.purple, bold = true, italic = true }
            hl["markdownH2"] = { fg = c.ui.purple, bold = true, italic = true }
            hl["markdownH3"] = { fg = c.ui.purple, bold = true, italic = true }
            hl["markdownH4"] = { fg = c.ui.purple, bold = true, italic = true }
            hl["markdownH5"] = { fg = c.ui.purple, bold = true, italic = true }
            hl["markdownH6"] = { fg = c.ui.purple, bold = true, italic = true }
            hl["markdownCode"] = { fg = c.syntax.green }
            hl["markdownCodeBlock"] = { fg = c.syntax.green }
            hl["@lsp.type.enumMember.markdown"] = { fg = c.syntax.cyan }
          end,
        },

How can I change style of current selected buffer in status line?

In my packer.lua file I have:

return require('packer').startup(function(use)
    ...
    use "AstroNvim/astrotheme"
    ...
end)

but the theme doesnt seem to be applying.

If I try to run the command
colorscheme astrodark
manually, then I get the following error:

Error detected while processing /home/turing/.local/share/nvim/site/pack/packer/s
tart/astrotheme/colors/astrodark.lua:
E5113: Error while calling lua chunk: ...pack/packer/start/astrotheme/lua/astroth
eme/lib/util.lua:44: attempt to index field 'palettes' (a nil value)
stack traceback:
        ...pack/packer/start/astrotheme/lua/astrotheme/lib/util.lua:44: in functi
on 'set_palettes'
        ...ite/pack/packer/start/astrotheme/lua/astrotheme/init.lua:14: in functi
on 'load'
        ...m/site/pack/packer/start/astrotheme/colors/astrodark.lua:1: in main ch
unk

We should refactor the colorscheme to decrease the number of colors in the palette, dynamic shade/hue/brightness generation for other necessary colors, rely on semantically sound links rather than hard setting each highlight group to improve startup time

My theme.lua file

local M = {}

local function config(_, _)
    return {
        palette = "astrodark",
        highlights = {
            global = {
                ["NeogitDiffDeleteHighlight"] = {
                    fg = "#292929",
                    bg = "#f77977",
                },
                ["NeogitDiffAddHighlight"] = {
                    fg = "#292929",
                },
                ["NeogitDiffDelete"] = { fg = "#292929", bg = "#f77977" },
                ["SpelunkerSpellBad"] = { fg = "NONE", bg = "NONE" },
            },
        },
    }
end

M.config = config
return M

init.lua

        {
            "AstroNvim/astrotheme",
            opts = theme.config,
        },

This was working fine until I updated, then the highlight customizations were not working anymore.

Confirmed by downgrading to v2.1.1 customizations working again.

Checklist

• Using a stable version of Neovim (i.e. not neovim nightly)
• :AstroUpdate
• Restarted AstroNvim

Operating system/version

macOS Ventura Version 13.2.1

Terminal/GUI

iterm2 and kitty

AstroNvim Health

AstroNvim ~

• AstroNvim Version: v3.10.3
• Neovim Version: v0.9.0
• OK Using stable Neovim >= 0.8.0
• OK git is installed: Used for core functionality such as updater and plugin management
• OK open is installed: Used for gx mapping for opening files with system opener (Optional)
• OK lazygit is installed: Used for mappings to pull up git TUI (Optional)
• OK node is installed: Used for mappings to pull up node REPL (Optional)
• WARNING gdu is not installed: Used for mappings to pull up disk usage analyzer (Optional)
• WARNING btm is not installed: Used for mappings to pull up system monitor (Optional)
• OK python3 is installed: Used for mappings to pull up python REPL (Optional)

Describe the bug

The default Astrotheme seems to have changed once I ran leaderpa to update. Screenshots provided below.
The colorscheme was correct until I ran leaderpa
Tested on 2 separate computers(work/personal), both same issues
Tested on iterm2 and kitty, both same issues

I tried removing Astronvim with:

rm -rf ~/.config/nvim
rm -rf ~/.cache/nvim
rm -rf ~/.local/share/nvim

Then just install base Astronvim, installing tsserver lsp and javascript/typescript treesitters. Same issue.

Updated to Neovim v0.9.0(was previously v0.8.3), same issues

Note: Ive only tested with JS/TS files

Steps to Reproduce

1. Install Astronvim
2. Open a JS/TS file, install treesitter
3. Notice colors are not same as astrodark gettings cyan methods and no bracket colorization, etc.

Expected behavior

Default astrodark theme

Screenshots

Before:

After:

Another screenshot with issue:

Additional Context

No response

E5113: Error while calling lua chunk: ...l/share/nvim/lazy/astrotheme/lua/astrotheme/lib/util.lua:44: attempt to index field 'palettes' (a nil value)
stack traceback:
	...l/share/nvim/lazy/astrotheme/lua/astrotheme/lib/util.lua:44: in function 'set_palettes'
	...local/share/nvim/lazy/astrotheme/lua/astrotheme/init.lua:14: in function 'load'
	.../.local/share/nvim/lazy/astrotheme/colors/astrolight.lua:1: in main chunk

I don't have any additional settings defined. Please forgive me if this is a dumb mistake on my part, but I can't seem to figure out what I'm doing wrong. Any help is appreciated!

Ideally, it would look like https://github.com/fxn/vim-monochrome

I also discovered Telescope's icons can be be "decolorized" when defaults.color_devicons=false, which looks great with the theme above.

I got this error when using without Astronvim, I thought it is standalone colorscheme

Could not load your colorscheme                                                                                                                                                   
...l/share/LazyVim/lazy/LazyVim/lua/lazyvim/config/init.lua:121: Vim:E5113: Error while calling lua chunk: ...hare/LazyVim/lazy/astrotheme/lua/astrotheme/lib/util.lua:44: attempt
 to index field 'palettes' (a nil value)
stack traceback:
^I...hare/LazyVim/lazy/astrotheme/lua/astrotheme/lib/util.lua:44: in function 'set_palettes'
^I...al/share/LazyVim/lazy/astrotheme/lua/astrotheme/init.lua:14: in function 'load'
^I...local/share/LazyVim/lazy/astrotheme/colors/astrodark.lua:1: in main chunk
^I[C]: in function 'colorscheme'
^I...l/share/LazyVim/lazy/LazyVim/lua/lazyvim/config/init.lua:121: in function <...l/share/LazyVim/lazy/LazyVim/lua/lazyvim/config/init.lua:117>
^I[C]: in function 'xpcall'
^I...ocal/share/LazyVim/lazy/lazy.nvim/lua/lazy/core/util.lua:110: in function 'try'
^I...l/share/LazyVim/lazy/LazyVim/lua/lazyvim/config/init.lua:117: in function 'setup'
^I...m/.local/share/LazyVim/lazy/LazyVim/lua/lazyvim/init.lua:5: in function 'setup'
^I...al/share/LazyVim/lazy/lazy.nvim/lua/lazy/core/loader.lua:330: in function <...al/share/LazyVim/lazy/lazy.nvim/lua/lazy/core/loader.lua:328>
^I[C]: in function 'xpcall'
^I...ocal/share/LazyVim/lazy/lazy.nvim/lua/lazy/core/util.lua:110: in function 'try'
^I...al/share/LazyVim/lazy/lazy.nvim/lua/lazy/core/loader.lua:338: in function 'config'
^I...al/share/LazyVim/lazy/lazy.nvim/lua/lazy/core/loader.lua:306: in function '_load'
^I...al/share/LazyVim/lazy/lazy.nvim/lua/lazy/core/loader.lua:180: in function 'load'
^I...al/share/LazyVim/lazy/lazy.nvim/lua/lazy/core/loader.lua:115: in function 'startup'
^I...im/.local/share/LazyVim/lazy/lazy.nvim/lua/lazy/init.lua:85: in function 'setup'
^I/Users/maksim/.config/LazyVim/lua/config/lazy.lua:10: in main chunk
^I[C]: in function 'require'
^I/Users/maksim/.config/LazyVim/init.lua:5: in main chunk
# stacktrace:
  - /LazyVim/lua/lazyvim/config/init.lua:121
  - /LazyVim/lua/lazyvim/config/init.lua:117 _in_ **setup**

I loved the previous astronvim's modest dark scheme and now I struggle to reverse it to a somewhat previous state. At least the main colours. For now, I rollbacked to the 1.7.0 version, but I'll be glad to have this option as well

Is your feature related to a problem?

Currently there's no support for Neogit. And without it Neogit is sadly unusable:

Describe the new feature

It would be nice to implement the highlights for Neogit.

Additional context

I am currently trying to do this myself, but since I don't have a lot of experience in working with highlight groups and colors in general, I'm not sure how well I'll be able to do it.
Also, since a colorscheme is a thing of taste, I'm not really sure, which colors you guys (as authors) would prefer :)

Checklist

• Using a stable version of Neovim (i.e. not neovim nightly)
• :AstroUpdate
• Restarted AstroNvim

Operating system/version

macOS 13

Terminal/GUI

iterm2

AstroNvim Health

but other theme is normal

Describe the bug

but other theme is normal

Steps to Reproduce

lazygit

Expected behavior

Screenshots

No response

Additional Context

No response

The value of italic_comments is not respected in lua/astrotheme/lib/config.lua, nor is the value in a user configuration:

    opts = {
      style = {
        italic_comments = true,
      },
    },

First of all let me applause the huge work you’ve done on the theme 👏 I love the default one ❤️
But I’ve been on a quest to find a decent light theme and I was hoping to find the same quality in the light version, but I find that the colours accessibility, specially text contrast, is way lower than the dark themes.
I know some themes have high contrast versions but I'm not requesting that here, merely to make it coherent with the default dark contrast levels.
I know we can all customise it, but I found that the default experience would benefit from a more coherent approach.

I understand colors are subjective, but I'm curious if anyone else finds crust a bit too "warm" (red) for this relatively "cool" gray theme? In my opinion, it looks out of place in this otherwise beautiful default theme. crust is used as the background for Neo-Tree as seen in this screenshot:

Interestingly, none of the screenshots for Astronvim or Astrodark seem to use this warm color for Neo-Tree either. If I measure the color in the official Astrodark screenshot, it is #1B1F27. So, I use that in my own configuration as seen in this screenshot, which matches the palette of the theme better:

Would anyone be opposed if I submitted a PR with the change?

The screenshot on the README is a bit dated now, we should update this for sure. I believe this would actually be a PR to astronvim.github.io repo

The palette and highlight overrides need to be fully extendable on a per-palette basis. Ideally with the option for table override for simple extensions and also a function override format that gets passed in the palette and highlight groups for full extension with arbitrary lua. Also just to note it needs to be "per palette" so that you can extend specific palettes

We should have a pretty complete README with documentation on the setup function, installation instruction with a few different plugin managers (packer, vim-plug, lazy.nvim), and maybe some screenshots

Add some more nice palettes, stuff like a light theme and maybe a few other nice dark color palettes

Checklist

• Using a stable version of Neovim (i.e. not neovim nightly)
• :AstroUpdate
• Restarted AstroNvim

Operating system/version

macOS 13.3.1 (a) (22E772610a)

Terminal/GUI

iTerm2

AstroNvim Health

==============================================================================
astronvim: require("astronvim.health").check()

AstroNvim ~

• AstroNvim Version: v3.15.5
• Neovim Version: v0.9.0
• OK Using stable Neovim >= 0.8.0
• OK git is installed: Used for core functionality such as updater and plugin management
• OK open is installed: Used for gx mapping for opening files with system opener (Optional)
• OK lazygit is installed: Used for mappings to pull up git TUI (Optional)
• OK node is installed: Used for mappings to pull up node REPL (Optional)
• OK gdu is installed: Used for mappings to pull up disk usage analyzer (Optional)
• WARNING btm is not installed: Used for mappings to pull up system monitor (Optional)
• OK python3 is installed: Used for mappings to pull up python REPL (Optional)

Describe the bug

When using folke/todo-comments.nvim I seem to have strange highlighting colors with the plugin enabled.

Steps to Reproduce

Not sure if it's a reprex but add this plug:

{
	"folke/todo-comments.nvim",
	event = "User Astrofile",
	config = function()
		require("todo-comments").setup({})
	end,
}

Then try adding a comment in a file

Expected behavior

The comments should render in color without the first chars being the wrong color.

Screenshots

Additional Context

No response