Fix vim

[GordianDziwis]

Description

Fixes #86.

What is still an issue, is that Vim defines other Default highlights than Nvim. Check ErrMsg highlight as an example.

Should we clear the used highlights by default, so that we start from a clean state? @JamyGolden?

Checklist

• I have included the built files ./colors/*.vim in a separate commit and followed the build instructions
• I have confirmed that my changes produce no regressions after building

[JamyGolden]

I don't see any ErrMsg, you might mean ErrorMsg but I don't see anything noticable about that line https://github.com/tinted-theming/tinted-vim/pull/89/files#diff-8e4da39bbefb342dbac24c7b8fe153c9e2b12798d48a2ea5a75721d462ed88faR304

Clearing highlights would make our job easier, but I'm worried it might break things unexpectedly. For example changing a theme with :colorscheme base16-oceanicnext would remove highlights added by plugins for example, unless I'm mistaken.

[GordianDziwis]

I don't see any ErrMsg, you might mean ErrorMsg but I don't see anything noticable about that line https://github.com/tinted-theming/tinted-vim/pull/89/files#diff-8e4da39bbefb342dbac24c7b8fe153c9e2b12798d48a2ea5a75721d462ed88faR304

Tinted-vim sets the foreground of ErrorMsg red, and vim sets the background red, which makes ErrorMsg unreadable.

Clearing highlights would make our job easier, but I'm worried it might break things unexpectedly. For example changing a theme with :colorscheme base16-oceanicnext would remove highlights added by plugins for example, unless I'm mistaken.

We would only clear the highlights set by tinted-vim, so highlights set by plugins should be untouched (unless we set them explicitly).

[JamyGolden]

Ah ok, yeah clearing the highlights we work with makes sense.

[PatTheMav]

Just checked the PR:

• The themes still don't support the old base16colorspace variable, even though the comment block above the fallback code makes explicit mention of this legacy variable (which is the original variable used to be enable this functionality)
• If I'm not mistaken, this following block in the plugin code is a guard against multiple initialisation:

if exists('g:tinted-vim')
    finish
endif
let g:loaded_yourplugin = 1

The tinted-vim global is never set in my tests (is it set by the Lua code). Also loaded_yourplugin sounds like the default variable used in some vim plugin template and should be changed to reflect the name of the plugin.

• The internal name of base16-material is base24-material. Is this intended? Because it still needs to be set as base16-material to take effect.

As I'm using colours set in the shell (kinda like base16-shell the different themes all look the same visually in my tests, but I did not encounter any vim errors while switching between them.

[GordianDziwis]

Thanks a lot for the review!

* The themes still don't support the old `base16colorspace` variable, even though the comment block above the fallback code makes explicit mention of this legacy variable (which is the original variable used to be enable this functionality)

Fixed, was a typo.

* If I'm not mistaken, this following block in the plugin code is a guard against multiple initialisation:

if exists('g:tinted-vim')
    finish
endif
let g:loaded_yourplugin = 1

The tinted-vim global is never set in my tests (is it set by the Lua code). Also loaded_yourplugin sounds like the default variable used in some vim plugin template and should be changed to reflect the name of the plugin.

You are right was an artifact from some template, I removed it.

* The internal name of `base16-material` is `base24-material`. Is this intended? Because it still needs to be set as `base16-material` to take effect.

Good catch!

As I'm using colours set in the shell (kinda like base16-shell the different themes all look the same visually in my tests, but I did not encounter any vim errors while switching between them.

Without set termguicolors the colors are defined by the terminal, so they should not change. I updated the README.md.