3

Not 100% sure if this is what you mean, but for me, when I'm running in the Linux console, $TERM is set to linux, and when I'm running in a terminal emulator it's set to e.g. xterm. (In GUI Vim it's entirely empty.) So: if $TERM == 'linux' set background=dark endif


3

You need to reorder the commands in your vimrc, to only set the colorscheme after the plug#end() call. call plug#begin('~/.vim/plugged') Plug 'embark-theme/vim', { 'as': 'embark' } call plug#end() colorscheme embark The reason why this is important is that plug#end() is what will modify the 'runtimepath' setting, which is what allows Vim to find plug-in ...


3

A brief word on how vim-plug works... The main part of a plugin config is a path on GitHub. In your case dracula/vim refers to https://github.com/dracula/vim. What vim-plug needs to do, then, is download/install (using git) the plugin code from that address. But it doesn't happen automatically. It's up to you to run the command :PlugInstall. (And do so each ...


3

You can't change colorscheme for a single window in vim (and probably in neovim too). But if you speak about different colors of regular neovim windows and built-in terminals, you can play around g:terminal_color_0..15. Usually modern colorschemes use them to set terminal colors to match colorscheme, e.g.: let g:terminal_color_0 = '#1c1c1c' let g:...


3

It's important that a theme set the g:colors_name variable correctly to match the name of the theme script file, because Vim will use it when it needs to reload the theme (and it does so in a few situations.) I could find at least one cobalt2 theme online that had a commit fixing it from incorrectly setting the variable to cobalt, to setting it correctly as ...


3

Setting 'background' adjusts the default colors for the UI highlight groups (*highlight-groups*), and resets the standard syntax highlight groups (*group-name*) to the default colors for the set background, and thus it must be set before syntax highlighting commands to prevent overriding. If it isn't set explicitly in .vimrc, or in a separate colorscheme ...


2

At the very least you should be able to check the global variable that holds the current color scheme... :if g:colors_name ==? "a" | colo b | endif g:colors_name is the variable that I'm talking about and we do a case-insensitive check against the scheme you mentioned, a. (Color schemes don't require you specify the correct case. Case-sensitive ...


2

Another quick (perhaps even lazy) fix is to just do something like: :colo desert This will change your color scheme, and in some cases will make hidden text become visible.


2

While Dalker's answer is technically correct, it's not entirely accurate, at least not anymore - the exact answer to this depends on your terminal emulator. Highlighting backgrounds is general is done by applying a background highlight (ctermbg or guibg) to the Normal highlight group. See :h background and this answer on SO. For terminals that only support ...


2

There's a web app I wrote that lets you create vim themes online and then export them easily. http://pintovim.dev/


2

Yes, it fixes the issue with colorschemes when they were unable to reset all linked highlight groups to their defaults. Now you can change gruvbox and solarized in the same vim session without "leaked" highlights. For the :hi def there was a simple fix -- vim considered a cleared highlight as the one that still had settings applied, thus preventing ...


2

The actual code of these two commits can be viewed online here and here. Roughly speaking, Vim now saves value of "def link" in a separate field of the internal "highlight" structure. So upon executing hi clear group(s) are not really cleared, but re-linked to their "def links" (if any). You can do a quick test like this: " ...


2

I suspect https://github.com/vim/vim/pull/6970 and related https://github.com/vim/vim/issues/4405 Basically, before the patch it was impossible to put vim into full "default colors mode" as there were no way to do it -- :hi link survived :hi clear. Also cleared highlight groups were impossible to set with :hi def groupname .... I guess that ...


1

As Chris Heithoff mentioned in comments, you need to make sure that the autoloader for the colorscheme is needed or not. There is generally a .txt file with install instructions or there "could be". It'll be under the 'doc' folder of that colorscheme repo.


1

The error I made is placing the colorscheme command before the source command. init.vim should look like the following: source $HOME/.config/nvim/vim-plug/plugins.vim colorscheme tokyonight


1

The lazy way is to put hi SpecialKey ctermbg=NONE in your .vimrc after calling in your favorite colorscheme. Else you can read this gist and learn some true vim wizardry : https://gist.github.com/romainl/379904f91fa40533175dfaec4c833f2f Why SpecialKey ? The answer resides at the end of the :help 'listchars' section of the help pages.


1

Just put the terminal colorscheme in your vimrc (usually ~/.vimrc or $HOME\_vimrc on Windows) and the gui colorscheme in your gvimrc. Create ~/.gvimrc / $HOME\_gvimrc if you don't already have that file. This works because gvimrc is only read when you run gvim and it is read in after vimrc


1

rxvt is recognized as 88-color terminal, so Vim makes use of several codes below 88. See here and below.


1

Try removing the backslashes from the parens. This is what works for me. call matchadd("PyBreakpoint", 'breakpoint()') with example file: this that breakpoint() other another


1

Looking into the source code of gruvbox-material/gruvbox I can see: https://github.com/gruvbox-community/gruvbox/blob/9e71159ffa93be1e772d2cb3c78ee940f7b308ba/colors/gruvbox.vim#L272 g:gruvbox_termcolors == 16 fallback to use terminal 16 colors which are only viable if you have set them properly in a terminal to match gruvbox colors. I suggest to add set ...


Only top voted, non community-wiki answers of a minimum length are eligible