Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

torte colorscheme's usage of highlight groups is suboptimal #274

Open
Tachi107 opened this issue Feb 15, 2025 · 1 comment
Open

torte colorscheme's usage of highlight groups is suboptimal #274

Tachi107 opened this issue Feb 15, 2025 · 1 comment

Comments

@Tachi107
Copy link

Hi! I'm opening this issue mentioning the torte colorscheme only since that's what I use, but this likely applies to others.

When using LSP Semantic Highlight, which properly marks functions, identifiers, etc., with the appropriate highlight groups, most of the code becomes of the same color, and readability is worsened.

The retrobox theme, for example, doesn't have this issue, since it maps Function to a different color.

Please see yegappan/lsp#483 for further details.

Bye!

@romainl
Copy link
Collaborator

romainl commented Feb 15, 2025

Our modernization efforts were mostly focused on:

  • bringing some coherence to the legacy colorschemes,
  • adding support for the many features that were added to Vim in the decades since their inclusion.

Tough choices had to be made, sometimes, but we generally respected the design choices of the original authors.

One such design choice, that all legacy colorschemes had in common, was that they were originally designed as "overlays" for the default colorscheme. They only redefined a bunch of highlight groups, leaving the rest untouched, and we mostly respected that. Even if we don't necessarily agree with it. Our goal was not to design a new torte or a new pablo, but to refresh them, so to speak.

Of the 17 legacy colorschemes, only three explicitly defined the Function highlight group: elflord, industry, and slate and so do their remakes. The others link Function to Identifier, like default has always done and like the originals did.

Of the 8 new colorschemes, only two explicitly define Function: retrobox and unokai.

Choosing to give Function a separate look from Identifier is a design choice that colorscheme authors might or might not make. Explicitly supporting third-party plugins or not is another choice that can be made, and one we decided against as we started this project. We think it is a can of worm that we don't want to open.

Speaking of choices, Vim links Function to Identifier by default. Most colorschemes distributed with Vim do the same. Some don't. Some third-party colorschemes do, others don't. The plugin author apparently makes the mistake of assuming that Function and Identifier look different while this is not the case out of the box.

So, what can you do?

  • Out of the 26 colorschemes distributed with Vim, 5 accidentally support what you and your plugin are trying to do so there is nothing particularly blocking, here. Use one of those and you are good.

  • If you absolutely want torte to have a special color for Function, you can do what is described under :help colorscheme-override:

    augroup MyColorOverrides
        autocmd ColorScheme torte hi Function guibg=NONE ctermfg=red ctermbg=NONE ctermfg=red
    augroup END
    colorscheme torte
    
  • Remind the plugin's author that Function and Identifier are identical by default, which might force him to make some changes to his code.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants