echasnovski / mini.nvim

Library of 40+ independent Lua modules improving overall Neovim (version 0.8 and higher) experience with minimal effort
MIT License
5.06k stars 185 forks source link

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

Closed 231tr0n closed 1 week ago

231tr0n commented 1 week ago

Contributing guidelines

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 image While in others it does not show properly image

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 commented 1 week ago

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 commented 1 week ago

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. image

echasnovski commented 1 week ago

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().