Cursorline in mini.hues is not highlighted properly in few lines.

[231tr0n]

Contributing guidelines

• I have read CONTRIBUTING.md
• I have read CODE_OF_CONDUCT.md
• I have updated 'mini.nvim' to latest version

Module(s)

mini.hues

Description

cursorline in mini.hues is not highlighted properly in few lines in mini.hues.
In some places it looks normal like below

While in others it does not show properly

Neovim version

nightly latest

Steps to reproduce

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 = {
		-- add any other plugins here
		"nvim-treesitter/nvim-treesitter",
		"echasnovski/mini.hues",
	},
})

require("nvim-treesitter.configs").setup({
	ensure_installed = { "svelte", "bash" },
	highlight = {
		enable = true,
	},
})

vim.cmd("set cursorline")
vim.cmd.colorscheme("default")
vim.cmd.colorscheme("randomhue")

With the above config open the file below with name *.svelte

<script>
  import Accordion from '$lib/components/page/Accordion.svelte';

  export let name = '';
  export let url = '';
  export let badges = [];
  export let description = '';
</script>

{#if name && description}
  <Accordion {name} {url}>
    <div class="center">
      {#each badges as badge}
        <span class="badge">{badge}</span>
      {/each}
      <div class="center">
        {description}
      </div>
    </div>
  </Accordion>
{/if}

<style>
  div.center {
    margin-top: 1em;
  }
</style>

Expected behavior

Cursorline should look uniform across all lines.

Actual behavior

Cursorline is not uniform across all lines.

[echasnovski]

This is not an issue with 'mini.hues' (or any color scheme, for that matter). This is the effect of tree-sitter highlighting: as it is done with extmarks, if highlight group defines background color, it is used on top of the cursorline. You can check which highlight group overrides cursorline by executing :Inspect in the target range.

[231tr0n]

This is not an issue with 'mini.hues' (or any color scheme, for that matter). This is the effect of tree-sitter highlighting: as it is done with extmarks, if highlight group defines background color, it is used on top of the cursorline. You can check which highlight group overrides cursorline by executing :Inspect in the target range.

But with tokyonight colorscheme, the same code works fine.

[echasnovski]

Running :Inspect at the position of the cursor in screenshot shows the following:

Treesitter
  - @none.svelte links to Normal svelte

As it links to Normal highlight group, it defines background which overrides cursorline (as this is how extmarks with background work).

This comes from 'nvim-treesitter/nvim-treesitter' and which has the following its 'CONTRIBUTING.md': @none ; completely disable the highlight. The 'mini.hues' module interprets "completely disable" as "disable both foreground and background" and does so by linking to Normal.

This particular use of @none comes from 'svelte' queries and seems intentional.

'folke/tokyonight.nvim' has different behavior because it ignores the @none capture completely, which doesn't align with documentation in 'nvim-treesitter/nvim-treesitter'.

---

If you don't like this behavior, you can follow the Tokyonight route and add vim.api.nvim_set_hl(0, '@none', {}) after enabling 'mini.hues' based color scheme. A more elaborate approach is to define @none to only have foreground from Normal, but that is left as an exercise in how to use vim.api.nvim_get_hl().

[echasnovski]

@231tr0n, @none now doesn't have explicit highlighting in 'mini.hues'. The main obstacle of "official" documentation on 'nvim-treesitter' is now gone (as it is transitioning to main branch which doesn't have @none documented), so it is finally "correct" to remove the link to Normal.