NvimTree file highlighted as bad spell (SpellCap)

[ayghri]

Description

The latest commit using "SpellCap" highlight group is a bad idea. Now many of the files in the tree are annoyingly marked as bad spelling. I don't want to mention names, but great job Mr Spelling Warrior who PR-ed this change

Neovim version

Nvim v0.9.4

Operating system and version

Gentoo

Windows variant

No response

nvim-tree version

latest commit as of today

Clean room replication

use latest commit and open tree to code files

Steps to reproduce

use latest commit and open tree to code files

Expected behavior

No SpellCap of files

Actual behavior

Simlinks and exec files highlighted for SpellCap

[gegoune]

I don't want to mention names, but great job Mr Spelling Warrior who PR-ed this change

This attitude is not only unnecessary but also unwelcome. This is an open source project so either you take it as is or open PR with changes you want to see if you think you can do better.

[ayghri]

This change has took me over hours to figure out, going through thousands of Lua configuration code and through the plugin source.

I apologize if my message came up as condescending, I tried to voice my complaint with humor, not to belittle the immense effort that goes in the plugin development.

[alex-courtis]

d9cb432 fix(#2415): disambiguate highlight groups, see :help nvim-tree-highlight-overhaul (#2639) Alexander Courtis Mon 12:43

https://github.com/nvim-tree/nvim-tree.lua/blob/master/doc/nvim-tree-lua.txt#L2397

2024-01-29: disambiguate default highlights sharing groups:

- NvimTreeRootFolder   PreProc   -> Title
- NvimTreeModified*    Constant  -> Type
- NvimTreeOpenedHL     Constant  -> Special
- NvimTreeBookmarkIcon Constant  -> NvimTreeFolderIcon
- NvimTreeExecFile     Constant  -> SpellCap
- NvimTreeImageFile    PreProc   -> SpellCap
- NvimTreeSpecialFile  PreProc   -> SpellCap
- NvimTreeSymlink      Statement -> SpellCap

One of the main drivers of this highlighting change was accessibility and compatibility.

[ayghri]

I got that part. (In my config, I used the same highlight group for all the special files)

But why SpellCap specifically? It seems an odd choice.

This is my PR. Let me know what you think

- NvimTreeExecFile     SpellCap -> Title
- NvimTreeImageFile    SpellCap -> NvimTreeNormal
- NvimTreeSpecialFile  SpellCap -> NvimTreeNormal
- NvimTreeSymlink      SpellCap -> NvimTreeSpecialFile

[alex-courtis]

But why SpellCap specifically? It seems an odd choice.

Distinct standard highlight groups that most closely match the functionaily are used wherever possible:

• 256 color, tui and linux 8 color term are now supported and visible
• Those with accessibility requirements can interact properly using accessibility software or specific color schemes
• Full color scheme / theme compatibily: all nvim-tree groups will be styled consistently and distinctly, with no highlight groups being difficult to see.

There are two grandfathered exceptions: WindowPicker and FolderIcon.

Why SpellCap? It is available and distinct. Users and color schemes generally override those groups anyway.

[ayghri]

I believe the argument still holds. SpellCap is a highlight group that serves a specific function (Mark first words that are not capitalized).

• My first reaction seeing it in the nvim-tree buffer was that spelling was enabled in the buffer, which made me go through my config to find the cause, only to find after meticulous investigation that it was the new highlight choices.

• Many others will surely have the same experience.

• The logical thing to do would be to avoid using a group that serves a built-in function in vim.

Do you agree that what I am poiting out is just wanting to follow good design practice?

Feel free to incorporate my PR in future PRs instead of creating an entire merge for just 4 lines of code.

[keithfancher]

Oh man, this has been driving me crazy! Thank you for filing this issue, if nothing else so I could find it :D

My first reaction seeing it in the nvim-tree buffer was that spelling was enabled in the buffer, which made me go through my config to find the cause, only to find after meticulous investigation that it was the new highlight choices.

Same!

Many others will surely have the same experience.

Yes :')

I believe the argument still holds. SpellCap is a highlight group that serves a specific function (Mark first words that are not capitalized).

I wholeheartedly agree. SpellCap is a highlight group that triggers my brain to think "something is wrong and should be fixed". It's been driving me nuts to see it (seemingly) randomly in my file tree. It didn't even occur to me that it could be signaling that a file is executable.

EDIT: As a note to anyone else who comes across this issue, the workaround is a bit buried in a comment on a closed PR. In any case, these settings are easy to override in your config:

Highlight groups may be overridden before and after nvim-tree setup e.g.

vim.cmd [[
:hi link NvimTreeSpecialFile NvimTreeNormal 
:hi link NvimTreeExecFile Title 
:hi NvimTreeSymlink guifg=red
]]

[keithfancher]

It didn't even occur to me that it could be signaling that a file is executable.

And speaking of which, executable files seem to be the only ones that show this behavior. According to the docs shouldn't it also be all of the following?

- NvimTreeExecFile     Constant  -> SpellCap
- NvimTreeImageFile    PreProc   -> SpellCap
- NvimTreeSpecialFile  PreProc   -> SpellCap
- NvimTreeSymlink      Statement -> SpellCap

For better or worse, that doesn't seem to be the case for me. But maybe this is a case of:

Users and color schemes generally override those groups anyway.

[alex-courtis]

Documented:

FAQ: https://github.com/nvim-tree/nvim-tree.lua/wiki/FAQ#why-do-i-see-spelling-highlights

readme: https://github.com/nvim-tree/nvim-tree.lua?tab=readme-ov-file#highlight

:help nvim-tree-quickstart-highlight :help nvim-tree-highlight-overhaul

[keithfancher]

Documented:

Awesome, thank you! Definitely will make this more discoverable for folks.

[endoze]

@alex-courtis I'm not sure I understand how using SpellCap like this adds any accessibility. I too ran into this issue and went through a lot of the same motions that @aghriss went through when my editor started behaving differently than the day prior. I didn't immediately recognize that the issue was local to nvim-tree given how complex my neovim setup is and the number of plugins that could have caused such behavior.

I don't understand how using a widely understood idiom of "this is spelled wrong" adds accessibility when showing which files are executable (or really any of the others that were written to use SpellCap).

I honestly believe this particular change is a decrease in the overall user experience and detracts from the default out of box experience. Adding customizations to highlight groups after the fact isn't terribly complicated and if I'm unable to distinguish something in particular due to color/etc, I can easily change the highlight group for a particular element so long as it has a unique group that doesn't have far reaching effects throughout my editor. And if I want it tied to another more global highlight group for consistent changes, I can also do so. But I think the default experience should not be to misuse a highlight group like SpellCap. It has a very specific meaning when applied in neovim and this change causes more confusion than anything else.

[alex-courtis]

I see. Let's change this.

Distinct groups were chosen as they would still function with cterm and terminals with less than 256 colours. Users with vision issues using, say, a custom colourscheme or screenreader will be able to see these distinct linked groups, with hardcoded colours being problematic.

I do personally know people with vision and mobility issues who are able to use vim, hence these concerns and stipulations.

What should they be? Candidates below, taken from xterm-16color

No Identifier as it is too visually similar to Directory, although it is not an accessibility issue.
Special and Type are undesirable as they conflicts with open/modified file.
Underline is available even on 8 colour linux terminal.

[ayghri]

I'd go with Question for ExecFile and SpecialFile.

[endoze]

@alex-courtis I'll have to toy around with these locally and see them for myself in both my setup and xterm-16color. I really appreciate you taking the time to investigate this further and consider changing away from SpellCap.

[alex-courtis]

Went with:

  -- File Text
  { group = "NvimTreeExecFile", link = "Question" },
  { group = "NvimTreeImageFile", link = "Question" },
  { group = "NvimTreeSpecialFile", link = "Title" },
  { group = "NvimTreeSymlink", link = "Underlined" },

Exec and special looked a bit odd so I swapped with Title.

Resisted the urge to use TODO. It's nice on 0.10 but garish on 0.9

[grzuy]

Exec and special looked a bit odd so I swapped with Title.

Note that with regards to special files highlighting you can also disable special highlight treatment with...

    require("nvim-tree").setup({
      renderer = {
        -- Don't have any special highlighting for README and others
        special_files = {}
      }
    })