lifepillar / vim-colortemplate

The Toolkit for Vim Color Scheme Designers!

The Toolkit for Vim Color Scheme Designers!

Colortemplate is a 100% VimScript plugin for Vim 8 or later, which makes it easy to develop color schemes. Its ambitious goal is to become the way to create new color schemes for Vim!

Features

• Generates color schemes that support all environments, from black&white to millions of colors, and both terminal and GUI Vim.
• Generates color schemes that load efficiently and have a consistent structure following best practices.
• Automatically provides xterm approximations for GUI colors.
• Imports any color scheme. You do not have to start from scratch!
• Provides a sophisticated style picker. Create color schemes in real-time directly within Vim!
• Displays information about the highlight group under the cursor.
• Computes useful statistics about your color scheme.
• Supports generating any kind of auxiliary files (say, autoload/gorgeous.vim or scripts/foo.sh).
• Has syntax completion for highlight groups, keywords and common colors.
• …And a lot more!

Colortemplate is fully documented: to learn everything about it, read :help colortemplate.txt.

Quick Start

Installing this plugin does not require anything special. If you need help, please first check the FAQ.

:edit templates/dark.colortemplate
:Colortemplate! ~/.vim
:colorscheme dark

The resulting color scheme will be written into ~/.vim/colors. See :help colortemplate.txt for detailed documentation.

Note: :Colortemplate and other plugin's commands are filetype-specific. That means that they are available only if the filetype is set to colortemplate. You may need to explicitly type :set ft=colortemplate to make them available in new buffers.

Colortemplate is based on a very simple but very flexible template format. This is a minimal template, which you can actually compile without warnings:

Full name:  My Gorgeous Theme
Short name: gorgeous
Author:     Me <[email protected]>

Variant:    gui 256
Background: dark

; Color palette
Color:      myblack #333333 ~
Color:      mywhite #fafafa ~

; Highlight group definitions
Normal      mywhite myblack

Term colors: mywhite mywhite mywhite mywhite mywhite mywhite mywhite mywhite
Term colors: myblack myblack myblack myblack myblack myblack myblack myblack

If you want to get a flavor of how Colortemplate can be used in the real world, take a look at some color schemes created with it: WWDC16 and WWDC17 (simple), or Gruvbox 8 and Solarized 8 (complex).

Contributions

Do you want to contribute? Do you have any suggestions on how to improve Colortemplate? Open an issue or submit a pull request!

vim-colortemplate's Issues

Feature request: change meaning of term=/t= and add cterm=/c=

In the highlight command, we can have three stylistic attributes:

• term=, for terminals without color support,
• cterm=, for terminals with color support,
• gui=, for the GUI.

Currently, colortemplate only has term=/t= and gui=/g=. The latter is OK but the former is ambiguous: it looks like it would apply to the final term= while it actually applies to the final cterm= in some cases (256 and 16 variants) and to the final term= in others (0 variant).

Would it be possible to do the following?

1. Disambiguate term=/t= and make it only apply to the final term=.
2. Add cterm=/c= to handle color terminals explicitly.

Clarify documentation on Variant

I don't understand what the documentation on the Variant feature is supposed to mean

For example, if you
declare:

Variant: 256 88
<
then you may use only base-256 colors between 0 and 87. On the other hand,
if you declare:

Variant: 256 8 4
<
you will be able to use all base-256 colors, but only the first four base-16
colors.

When 256 88 means base-256 but only the first 87, then why doesn't 256 8 4 mean base-256 but only the first 4? Later on it's explained what output is generated from these values, but here it seems that declaring multiple values just renders multiple t_Co blocks. That would imply that declaring multiple number values for the same Variant is redundant since if color definitions apply to a t_Co >= 8 they automatically also apply for 256. Meaning 256 8 4 wouldn't make much sense since the >= 4 includes the 8 and 256 anyway.

Buuuuuuuuuuuuuut I'm guessing I'm misunderstanding something here.

Windows paths problem

I could fix it by replacing this line with:

if match(substitute(l:path, '\', '/', 'g'), '^' . substitute(l:dir, '\', '/', 'g')) == -1

The match function doesn't seem to like backslashes much, this:

match('C:\abc', '^C:\abc')

returns -1 and this as well:

match('C:\\abc', '^C:\\abc')

so escaping it doesn't help.

error if defining color as name

I get a streak of errors if I write something like:

Color:	    peru		peru ~

The colorscheme seems to be generated correctly, maybe it's something in the statistic generations?

cterm definitions for templates with dark and light backgrounds

If template has definitions for both dark and light, dark has only gui definitions:

hi clear
let g:colors_name = 'habamax'

let s:t_Co = exists('&t_Co') && !empty(&t_Co) && &t_Co > 1 ? &t_Co : 1

hi! link ErrorMsg Error
hi! link FoldColumn LineNr
hi! link LineNrAbove LineNr

..........

if &background ==# 'dark'
  let g:terminal_ansi_colors = ['#262626', '#d75f5f', '#87af87', '#afaf87', '#5f87af', '#af87af', '#5f8787', '#949494', '#626262', '#d7875f', '#afd7af', '#d7d787', '#87afd7', '#d7afd7', '#87afaf', '#bcbcbc']
  hi Normal guifg=#bcbcbc guibg=#262626 gui=NONE cterm=NONE
  hi Statusline guifg=#262626 guibg=#949494 gui=NONE cterm=NONE

  .............

  unlet s:t_Co
  finish
endif

Not working inside neovim

Hi,

I wanted to add highlighting to templates for this issue lifepillar/vim-solarized8#42 (comment) , and when i came to the part where i need to rebuild colorscheme by colortemplate, i got an error in the middle of the building:

[Colortemplate] Vim(return):E117: Unknown function: isnan

Then i tried to find isnan in help, and really the function doesn't exist.

My neovim version: NVIM v0.3.0-dev

Italics don't work in neovim

Generated colorschemes have this line:

let s:italics = (&t_ZH != '' && &t_ZH != '�[7m') || has('gui_running')

But in neovim this will not work (it needs || has('nvim') as well).

make highlighting consistent # vs ;

The old comment with vim code is highlighted differently with the new one:

WIP feature: real-time style picker!

For a while I have been thinking hard about how nice it would be to be able to update highlight groups in real-time using a style picker inside Vim. I have long pondered about the design and implementation of such a feature (less easy than you may think—especially the design part), but I believe I have finally nailed it (at least, the path is clear in my mind). Thanks to Vim popups and text properties! The code is far from finished and it is not published yet, but this is a draft of how it might look like:

Not too polished, I know, but I am so excited about this feature! From top to bottom, you see:

• the name of the current highlight group: this may be fixed, or it may change as you move the cursor to pick the highlight group under the cursor;
• RGB “sliders”;
• Information about the current style: hex and term values, whether this is a foreground/background/special color, and letters for attributes (B = bold, I = italic, etc.).
• Recent and favourite colors: the idea is that one could access frequently used colors there (you don't see any colors because the feature does not exist yet).

If you like this idea, or have any questions, please give me some feedback!

Should not to change pwd to colortemplate dir

reproduce:

1. :pwd -> ~/.config/nvim
2. open ~/.config/nvim/templates/theme.colortemplate
3. :Colortemplate!
4. :pwd -> ~/.config/nvim/templates

thx.

Can you generate a colortemplate based on the current colorscheme?

It would be great for converting manually-created colorschemes to colortemplate if colortemplate had a command to generate your initial template.

Error when sourcing a colorscheme if 'compatible' is set

See vim/colorschemes#55:

---

When 'compatible' is set, 'cpoptions' contains C and according to :help 'cpoptions':

C   Do not concatenate sourced lines that start with a
    backslash.  See |line-continuation|.

Therefore, when sourcing a color scheme file, lines like these throw an error:

let g:terminal_ansi_colors = ['#ffffff', '#0000ff', '#00cd00', '#cd00cd',
      \ '#008b8b', '#0000ff', '#ff1493', '#bcbcbc', '#ee0000', '#0000ff',
      \ '#00cd00', '#cd00cd', '#008b8b', '#0000ff', '#ff1493', '#000000']

Now you might wonder "Why on earth would anyone set 'compatible' in 2021?". Good question. A likely scenario is when starting Vim without a vimrc, for example with vim -u NONE. Without a vimrc, 'compatible' is set by default. So doing something like this this gives an error:

vim -u NONE -c "colorscheme blue"

---

Getting around a vim bug

The vim version I generally use (vim 8.0, debian stable) has this bug:

https://www.reddit.com/r/vim/comments/22krs1/using_set_backgrounddark_in_vim_resets_the/
https://groups.google.com/forum/#!msg/vim_dev/afPqwAFNdrU/nqh6tOM87QUJ

Basically, setting ctermbg to a value != 0 makes the &background light.

Possible workarounds:

1. simplest fix seems this (putting set bg at the end of the scheme)

2. to split groups in blocks like:

if &termguicolors || has('gui_running') || has('nvim')
  hi Normal guifg=#c5d4dd guibg=#1e1e1e guisp=NONE cterm=NONE gui=NONE
  hi MatchParen guifg=#ff0000 guibg=NONE guisp=NONE cterm=NONE gui=NONE
else
  hi Normal ctermfg=252 ctermbg=0 cterm=NONE
  hi MatchParen ctermfg=196 ctermbg=NONE cterm=NONE
endif

Note that I include cterm= in the first section because terminal vim (not neovim or newer vim versions) even tends to mix settings when using termguicolors.

It would also speed up colorscheme loading, but n.1 seems much easier.

Hash sign (#) is overloaded in Colortemplate: use new symbol for comments

Since commit 53b56ba Colortemplate has used # as the prefix for convenient one-line verbatim blocks (#if, #let, etc.). But Colortemplate uses # also for comments (and for hex colors—but that is a context-sensitive use). As pointed out by @mg979 in #14 (comment), it would be better to use different symbols. I like#if, #let, etc. because they remind me of C macros. So, I plan to introduce a new symbol for line comments and deprecate # for comments. The question is: which symbol?

My initial choice was %, as in TeX (Knuth is always right 🙂). But then I thought that% might be useful in future extensions of Colortemplate, e.g., to specify colors using percentages (?).

My current preference goes to ;, as in assembly (yes, I know: C, assembly… I am old school).

I will leave this issue open for comments for a while.

For reference, these are commonly used symbols from various programming languages (source):

;   As in Algol 60 and assembly
--  As in SQL
//  As in C/C++
!   As in FORTRAN 90
'   As in Visual Basic .NET
%   As in TeX

:Colortemplate not available in all buffers (was: Can't install with vim8's Packages)

I've just tried to install this plugin with vim8's native packages manager.
Issued command:
git submodule add [email protected]:lifepillar/vim-colortemplate pack/plugins/start/vim-colortemplate
And tried in vim :Colortemplate .vim, folder .vim existed and the command issued under home user. But gave me error: Not and editor command: Colortemplate
I checked in start folder and vim-colortemplate existed along with all of its files/folders.

New highlight group added: CurSearch

vim/vim#10133 adds a new highlight group, CurSearch.

Related: vim/colorschemes#159

Neovim: E518: Unknown option: balloonexpr=colortemplate#syn#balloonexpr()

I'm getting the following error on loading the filetype plugin. I tried both on Neovim stable 0.4.4 and nightly 0.5.0.

❯ nvim --version
NVIM v0.4.4
Build type: Release
LuaJIT 2.0.5
Compilation: /usr/bin/clang -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=1 -DNDEBUG -DMIN_LOG_LEVEL=3 -Wall -Wextra -pedantic -Wno-unused-parameter -Wstrict-prototypes -std=gnu99 -Wshadow -Wconversion -Wmissing-prototypes -Wimplicit-fallthrough -Wvla -fstack-protector-strong -fno-common -fdiagnostics-color=auto -DINCLUDE_GENERATED_DECLARATIONS -D_GNU_SOURCE -DNVIM_MSGPACK_HAS_FLOAT32 -DNVIM_UNIBI_HAS_VAR_FROM -I/tmp/neovim-20200808-89283-1us0ytm/neovim-0.4.4/build/config -I/tmp/neovim-20200808-89283-1us0ytm/neovim-0.4.4/src -I/usr/local/include -I/tmp/neovim-20200808-89283-1us0ytm/neovim-0.4.4/deps-build/include -I/Library/Developer/CommandLineTools/SDKs/MacOSX10.15.sdk/usr/include -I/usr/local/opt/gettext/include -I/tmp/neovim-20200808-89283-1us0ytm/neovim-0.4.4/build/src/nvim/auto -I/tmp/neovim-20200808-89283-1us0ytm/neovim-0.4.4/build/include
Compiled by brew@Catalina

Quick look at :help 'balloonexpr' shows that it's removed?

Plan for Colortemplate v3

I'd like to share my current vision for medium/long term development of this project, as a note for myself and also to receive feedback. Nothing below is cast in stone.

This plugin has reached some maturity and, given the ratio of open issues vs stars, I'd say that it's quite stable, although the code is a bit of a mess. It has also become somewhat complex. Besides, last weekend I have started to play with Vim9 script and I was pleasantly surprised how far it's got already. Its performance is also striking: I have measured an order of magnitude improvement in the computation of ΔE (one of the mathematical functions heavily used by Colortemplate). So, what I plan to do is:

• Freeze v2.1 feature-wise.
• Modularize the plugin. Turning it into a package might be appropriate: for instance, the style picker could become a plugin by itself (btw, are there plugin managers capable of dealing with packages?)
• Rewrite Colortemplate in Vim9 script. I have already done that (privately) for the test mini-framework, and I have found it pretty easy to do. This would massively help achieving modularization, given the new “import/export” features of Vim9.
• In the process, update the data structure used to represent a color scheme internally. The current structure is the result of a series of very ad hoc patches added over time. To make the plugin easily extendible, I plan to use a purely relational (as in: the Relational Model) schema. I was even thinking to use SQLite for that, but implementing some relational algebra operators is not difficult, so I plan to remain 100% pure Vim script. Why this approach? you may ask. Consider this example: at a certain point during development, I wanted to keep track of “critical” pairs of colors (those that are currently shown in a template's stats). Since I had not foreseen that requirement, I had to add a data structure and modify various parts of the code to maintain such information. In the new purely relational approach I envisage, that would have required only writing a suitable query (given a good data model, of course, but I have that). Another advantage would be that the performance (I estimate) would mostly depend on the efficiency of such relational operators. The first implementation might be trivial and rather inefficient, but it could be improved over time without changing anything else in the code.
• (This might be especially of interest to @romainl and @habamax) I plan to give precedence to a purely declarative (“strict”) subset of the Colortemplate syntax, suitable for color schemes to be included in Vim: no verbatim blocks, no help/auxfiles, and some other restrictions. This would provide more flexibility for generating the output because highlight group definitions in the template could be freely reordered (currently, the order of statements in a template must be kept in the output because verbatim blocks may be interspersed anywhere).
• Over time, I plan to reimplement the whole (“extended”) syntax, for people wanting the full expressive power of Colortemplate.

I think that's all for now. I'll update this thread if something else comes off my mind. Ah, no ETA for now, but don't expect this to be ready tomorrow… or next month 😉

Parse error

It works before f9ad4e7.

In my template I have

Include: vslight

but file has no extension (I don't use extension on template).

Requirement for `set hidden`... Why?

Requirement for set hidden makes things awkward in a way...

Readme suggests starting with :edit templates/default_clone.colortemplate but that fails if hidden is not set.

Is the expectation that this should be set in our .vimrc?

Is perhaps using setlocal bufhidden=hide only on the ft=colortemplate buffer an alternative option that would solve a similar problem?

Otherwise, can you please describe what the exact problem that requires set hidden is? (A reproducer for the problem when that's unset and that check commit is absent would be useful.) I'd be happy to look at other possibilities.

Cheers!
Filipe

[Colortemplate] Vim(if):E121: Undefined variable: get

With the recent version of vim-nightly I get E121 error on :Colortemplate!

vim version:

VIM - Vi IMproved 8.2 (2019 Dec 12, compiled Aug  5 2020 22:02:19)
MS-Windows 64-bit GUI version with OLE support
Included patches: 1-1377
Compiled by appveyor@APPVYR-WIN
Huge version with GUI.  Features included (+) or not (-):
+acl                +cmdline_compl      -ebcdic             +insert_expand      +mksession          +popupwin           +spell              -tgetent            +wildmenu
+arabic             +cmdline_hist       +emacs_tags         +ipv6               +modify_fname       -postscript         +startuptime        +timers             +windows
+autocmd            +cmdline_info       +eval               +job                +mouse              +printer            +statusline         +title              +writebackup
+autochdir          +comments           +ex_extra           +jumplist           +mouseshape         +profile            -sun_workshop       +toolbar            -xfontset
+autoservername     +conceal            +extra_search       +keymap             +multi_byte_ime/dyn +python/dyn         +syntax             +user_commands      -xim
+balloon_eval       +cryptv             -farsi              +lambda             +multi_lang         +python3/dyn        +tag_binary         +vartabs            +xpm_w32
-balloon_eval_term  +cscope             +file_in_path       +langmap            +mzscheme/dyn       +quickfix           -tag_old_static     +vertsplit          -xterm_save
+browse             +cursorbind         +find_in_path       +libcall            +netbeans_intg      +reltime            -tag_any_white      +virtualedit        
++builtin_terms     +cursorshape        +float              +linebreak          +num64              +rightleft          +tcl/dyn            +visual             
+byte_offset        +dialog_con_gui     +folding            +lispindent         +ole                +ruby/dyn           -termguicolors      +visualextra        
+channel            +diff               -footer             +listcmds           +packages           +scrollbind         +terminal           +viminfo            
+cindent            +digraphs           +gettext/dyn        +localmap           +path_extra         +signs              -termresponse       +vreplace           
+clientserver       +directx            -hangul_input       +lua/dyn            +perl/dyn           +smartindent        +textobjects        -vtp                
+clipboard          -dnd                +iconv/dyn          +menu               +persistent_undo    +sound              +textprop           +wildignore         
   system vimrc file: "$VIM\vimrc"
     user vimrc file: "$HOME\_vimrc"
 2nd user vimrc file: "$HOME\vimfiles\vimrc"
 3rd user vimrc file: "$VIM\_vimrc"
      user exrc file: "$HOME\_exrc"
  2nd user exrc file: "$VIM\_exrc"
  system gvimrc file: "$VIM\gvimrc"
    user gvimrc file: "$HOME\_gvimrc"
2nd user gvimrc file: "$HOME\vimfiles\gvimrc"
3rd user gvimrc file: "$VIM\_gvimrc"
       defaults file: "$VIMRUNTIME\defaults.vim"
    system menu file: "$VIMRUNTIME\menu.vim"
Compilation: cl -c /W3 /nologo  -I. -Iproto -DHAVE_PATHDEF -DWIN32  -DFEAT_CSCOPE -DFEAT_TERMINAL -DFEAT_SOUND -DFEAT_NETBEANS_INTG -DFEAT_JOB_CHANNEL -DFEAT_IPV6   -DFEAT_XPM_W32   -DWINVER=0x0501 -D_WIN32_WINNT=0x0501 /source-charset:utf-8 /MP -DHAVE_STDINT_H /Ox /GL -DNDEBUG  /Zl /MT /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE -DFEAT_OLE -DFEAT_MBYTE_IME -DDYNAMIC_IME -DFEAT_GUI_MSWIN -DFEAT_DIRECTX -DDYNAMIC_DIRECTX -DFEAT_DIRECTX_COLOR_EMOJI -DDYNAMIC_ICONV -DDYNAMIC_GETTEXT -DFEAT_TCL -DDYNAMIC_TCL -DDYNAMIC_TCL_DLL=\"tcl86t.dll\" -DDYNAMIC_TCL_VER=\"8.6\" -DFEAT_LUA -DDYNAMIC_LUA -DDYNAMIC_LUA_DLL=\"lua53.dll\" -DFEAT_PYTHON -DDYNAMIC_PYTHON -DDYNAMIC_PYTHON_DLL=\"python27.dll\" -DFEAT_PYTHON3 -DDYNAMIC_PYTHON3 -DDYNAMIC_PYTHON3_DLL=\"python38.dll\" -DFEAT_MZSCHEME -I "C:\Program Files\Racket\include" -DMZ_PRECISE_GC -DDYNAMIC_MZSCHEME -DDYNAMIC_MZSCH_DLL=\"libracket3m_a36fs8.dll\" -DDYNAMIC_MZGC_DLL=\"libracket3m_a36fs8.dll\" -DFEAT_PERL -DPERL_IMPLICIT_CONTEXT -DPERL_IMPLICIT_SYS -DDYNAMIC_PERL -DDYNAMIC_PERL_DLL=\"perl528.dll\" -DFEAT_RUBY -DDYNAMIC_RUBY -DDYNAMIC_RUBY_DLL=\"x64-msvcrt-ruby240.dll\" -DRUBY_VERSION=24 -DFEAT_HUGE /Fd.\ObjGXOULYHTRZAMD64/ /Zi
Linking: link  /nologo /opt:ref /LTCG:STATUS /HIGHENTROPYVA:NO oldnames.lib kernel32.lib advapi32.lib shell32.lib gdi32.lib  comdlg32.lib ole32.lib netapi32.lib uuid.lib /machine:AMD64 gdi32.lib version.lib   winspool.lib comctl32.lib advapi32.lib shell32.lib netapi32.lib  /machine:AMD64  libcmt.lib oleaut32.lib user32.lib  /nodefaultlib:lua53.lib  /STACK:8388608  /nodefaultlib:python27.lib /nodefaultlib:python38.lib   "C:\Tcl\lib\tclstub86.lib" winmm.lib WSock32.lib Ws2_32.lib xpm\x64\lib-vc14\libXpm.lib /PDB:gvim.pdb -debug

It was OK in v8.2.1360 as far as I remember and it is OK on neovim-nightly.

Documentation needed

It's not really clear how one is supposed to use the tool and how to interact with it. What's trivial and obvious for the developer may be obscure to the user with less (or no) background.

Eg.
I wasn't able to reproduce the pop up interaction, either in Nvim or Vim from terminal (URxvt) or GVim, all of them with and without my configs. And because of the missing docs I don't know if I'm doing something wrong or if there is a bug.

feature request: leave 256color - rgb hex somewhere for terminal configuration

Put somewhere a list of 256color approximations and respective rgb hex values when generating a scheme. I barely ever see decimal rgb values used anywhere. Maybe it's worth replacing rgb() with hex values in the comment, or just add another field there?

How this can be useful: to make generating something like this easier (can't use that one with vim-gruvbox8, for instance, since approximations are different).

v2 behavior differs from v1

After upgrading to v2 (commit b0e814) the color definitions are different for highlight groups with none values.

As an example we can compare SignColumn for v1 and v2. It looks like v2 skips ctermfg/ctermbg definitions for the gui variant, and this lets these values be overridden by the default color scheme highlights (that are built into Vim, not defined in colors/default.vim.

Output of verbose hi SignColumn in v1:

SignColumn     xxx term=standout
    Last set from [...]/colors/mysticaltutor.vim line 61

v2:

SignColumn     xxx term=standout ctermfg=14 ctermbg=242
    Last set from [...]/colors/mystical_v2.vim line 59

It could be intended behavior, then template writers can be expected to specify fg and bg to hl-Normal values. But I am not sure that can exactly replicate the old behavior for cases where overriding certain highlights are intended, like CursorLine, Visual or diff highlights.

Possible to have easy if/else blocks?

If I have blocks like:

verbatim
if &termguicolors || has('gui_running')
endverbatim
	FoldColumn		skyblue		nightblue
verbatim
else
endverbatim
	FoldColumn		skyblue		none
verbatim
endif
endverbatim

I think this format would be more readable:

If &termguicolors || has('gui_running')
	FoldColumn		skyblue		nightblue
Else
	FoldColumn		skyblue		none
Endif

That is, to treat uppercase If/Else/etc as one-line verbatim blocks. I tried it to implement it myself but I couldn't do it.

Invalid expression error when loading colorscheme

I'm playing around with vim-colortemplate for the first time, trying to create a colorscheme. The template is hosted on this Github repository.

It works fine on my Windows setup, where I use gvim. However, it has an error on my Linux setup, where I use neovim (v0.7.2) in the alacritty terminal (v0.10.1). Upon setting the colorscheme with :colorscheme dao, I get the following errors:

Error detected while processing .vim/colors/dao.vim:
line   16:
E15: Invalid expression: ? 0) : -1
line  122:
E121: Undefined variable: s:t_Co
line  191:
E121: Undefined variable: s:t_Co

In the generated dao.vim script, this is the line 16 which causes the issue:

let s:t_Co = exists('&t_Co') && !has('gui_running') ? (&t_Co ?? 0) : -1

After this error message, the colorscheme appears to works properly, but it's annoying to have the error every time.

I don't know the vim script syntax so I have no clue why it doesn't work, but given that this is generated through vim-colortemplate, I thought I would report it here.

alternative to changing saturation?

I wanted to try out the new inlay hints in vim, now that I have a whole stack that supports them (vim, vim-lsp, Go settings, and gopls). I wanted the hints to show up in a lighter color than the default, which just uses Normal. I'm using vim-solarized8 and have been doing my experimentation with the light background. I discovered this plugin (and OMG, it's awesome), but was unable to get what I wanted.

Specifically, I wanted to start with Normal and move the foreground color along the path towards the background color. I guess it's sort of like changing saturation, but with the background as a target instead of white. It seems like this would probably be more useful for a color theme design tool than traditional saturation, except when choosing a base color.

Does this make sense? I don't know color much at all, so perhaps not.

Vim(bdelete):E94:

Reproduction steps:

• :Colortemplate!
• open generated colorscheme in same window
• b # back to template
• generate again, ok
• b # back to generated colorscheme, but it's now an unlisted buffer
• b # back to template
• :Colortemplate! fails with error E94

Is it really needed to delete the buffer? At least using :bwipeout this wouldn't happen.

Fallback to 16 colors without option

Is there a way to allow falling back to 16 colors if 16 <= &t_Co < 256 but keeping the default 256 fallback if t_Co == 256? Right now I can set Terminal Colors: 256,16 which fails with 16 colors if @optionprefix_use16 = 1 is not set and forces 16 colors otherwise.

Also, thank you for developing this tool. It's great for creating well-behaving colorschemes by default and is much easier than creating a colorscheme script from scratch.

hex color is treated as old style comment

For the colors with UPPERcased letters:

update commentstring to reflect changes from # to ;

Using vim-commentary I get deprecated comments # instead of ;.

vim-colortemplate/ftplugin/colortemplate.vim

Line 22 in c4335e3

setlocal commentstring=#%s

Possible to include any code block before anything else?

I put dark and light variants in different files, normally I'd do:

this in the dark variant:

if &background == 'light'
  exe "so ".fnamemodify(expand('<sfile>:p'), ":h")."/vslight.vim"
  finish
endif

and this in the light variant:

if &background == 'dark'
  exe "so ".fnamemodify(expand('<sfile>:p'), ":h")."/vsdark.vim"
  finish
endif

In the colortemplate I have this just after the header:

Include: _vscommon

#===================================================================
# Dark variant
#===================================================================

Background: dark

with _vscommon:

# vim: ft=colortemplate
verbatim
if &background == 'light' && expand('<sfile>:t') == "vsdark.vim"
  exe "so ".fnamemodify(expand('<sfile>:p'), ":h")."/vslight.vim"
  finish
elseif &background == 'dark' && expand('<sfile>:t') == "vslight.vim"
  exe "so ".fnamemodify(expand('<sfile>:p'), ":h")."/vsdark.vim"
  finish
endif
call vsd#init()
let s:load_for = { ft -> g:VSD[ft] || g:VSD.extra_syntax }
endverbatim

But what I get in the colorscheme is:

if !(has('termguicolors') && &termguicolors) && !has('gui_running')
      \ && (!exists('&t_Co') || &t_Co < 256)
  echoerr '[Vim Studio Dark] There are not enough colors.'
  finish
endif

set background=dark

hi clear
if exists('syntax_on')
  syntax reset
endif

let g:colors_name = 'vsdark'

if &background == 'light' && expand('<sfile>:t') == "vsdark.vim"
  exe "so ".fnamemodify(expand('<sfile>:p'), ":h")."/vslight.vim"
  finish
elseif &background == 'dark' && expand('<sfile>:t') == "vslight.vim"
  exe "so ".fnamemodify(expand('<sfile>:p'), ":h")."/vsdark.vim"
  finish
endif
call vsd#init()
let s:load_for = { ft -> g:VSD[ft] || g:VSD.extra_syntax }

That is, my block is put after background is set, and it can't run. And since it could terminate the script, I'd want it really before anything else.

This is done with Include, but with verbatim (it would have been easier and I tried it first) it's the same.

Could that verbatim block be run before all the rest? Thanks

Variant: 0

The lowest supported variant is currently 2 based on the assumption that cterm* are ignored in favor of term when &t_Co <= 2. This is wrong because cterm* are definitely used when &t_Co == 2:

and ignored when &t_Co < 2:

Note that the behavior of 2 is generally the same as that of 8 except for these differences:

• when using color names, red/darkred and blue/darkblue are switched, as well as yellow/darkyellow and cyan/darkcyan: ctermbg=darkred gives you whatever the terminal emulator thinks is darkblue and so on,
• when using color indices, colors are in the standard "xterm" order: 1 is darkred, etc.

There is no difference between 1 and 0.

Includes with parameters?

Hi,

I recently found myself in a situation in which I needed to pass parameters to an Included template that contained an auxfile block. When built with colour scheme a, I wanted @guired to be used in a particular place in this auxfile. However, when built with colour scheme b, @guired should be replaced with @guigreen. In other words, I need some way to vary a small portion of the contents of an auxfile/Include.

race condition with `:Colortemplate!` in neovim nightly

Sometimes, when running :Colortemplate! (usually takes two calls to reproduce, but sometimes it happens on the first call. It's very race-conditiony), it will fail with this error:

Error detected while processing function colortemplate#make[56]..<SNR>72_print_error_msg[1]..<SNR>72_clearscreen:
line    1:
E315: ml_get: invalid lnum: 199
Press ENTER or type command to continue

and i'm left on a hidden, unnamed buffer with only 2 lines:

" Name:         Gruvburn
" Author:       Myself <[email protected]>

Commenting out these lines seems to fix this:

vim-colortemplate/autoload/colortemplate.vim

Lines 140 to 141 in 1edc68b

	wincmd p
	execute winnr('#') 'wincmd c'

I cannot reproduce this on vim (where exists('*appendbufline') == 1)

coloring is not cleared properly and affects other schemes

Let's say I have this template:

# vim: ft=colortemplate
Full name:  example for bug report
Short name: test
Author:     JW <[email protected]>

Background: dark

# Color palette
Color: bg_0          #181818        ~        none
Color: fg_0          #b9b9b9        ~        none
Color: green         #70b433        ~        DarkGreen

# Highlight group definitions
Variant:    gui 256 8

Normal        none  none
ShDerefSimple green none
ShDerefVar    green none

When I start Vim with default colorscheme, a piece of shell script will look like this (note magenta var HISTFILE):

Then I switch to the scheme generated with colortemplate (:colorscheme test), and vars become green:

So far so good. But when I try to go back (:colorscheme default), vars are... not colored at all:

So, it seems there are some leftovers that affect other schemes :/

It happens in vim and gvim, version 7.4 and 8.0.

Template parsing requires `ignorecase`

The field name search strings are lowercase, whereas the field names in the templates start with an upper-case character. Therefore, template parsing fails when ignorecase is not set.

Document that :Colortemplate requires special filetype

I've just hit a problem described in #5 - I had opened a template file before installing the plugin, so the filetype was not set and :Colortemplate was reported as missing. @lifepillar I think it should be explained in repo README (and perhaps in vim help, too - I haven't found it in getting started).

Fix colorscheme switching problems at template level

(Original issue from @jordwalke at #2)

You might take a look at @xolox's comment here about some known issues with colorscheme switching. If creating a template for other plugins to be based on, there might be some problems with colorscheming you can fix at the template level.

Wiki is wrong about installation without a plugin manager?

The Wiki says, in the FAQs section:

It's simple even without a plugin manager because vim-8+ provides package feature, see: :h package . Simply clone/download the repository and put it in ~/.vim/pack/vim-colortemplate

I think this is not quite right. To automatically load the plugin, the directory should be

~/.vim/pack/foo/start/vim-colortemplate

where foo could be any other name. To make the plugin optional instead, the directory should be

~/.vim/pack/foo/opt/vim-colortemplate

Then the plugin can be sourced by doing :packadd vim-colortemplate.

Explicitly inform users on how to install this plugin

Great hackable tool!

It might help potential users if there's a sentence or two on how to install this extension. For example,

Plug 'lifepillar/vim-colortemplate'

Unless, we're supposed to fork it and use it?
Always happy to send a PR.

Commit `c7f0542` breaks compilation of vim-solarized8

When the latest version of vim-solarized8 is compiled with versions after commit c7f0542, loading the colour scheme reports errors stemming from the fact that s:termtrans is unset, but finish is omitted. Compiling using the version in commit c66f4e5 produces a working colour scheme with finish present after each unsetting of s:termtrans. I don't know enough about colour schemes or colortemplate to know the cause of this.

I wasn't sure if this was a vim-colortemplate issue or a vim-solarized8 issue since I wasn't sure what stability guarantees vim-colortemplate intends to provide, but I assumed that since I couldn't find any mention of this change being a breaking change, it was probably not known/intended.

Black on 256 colors being ignored

First, kudos for the great project! Thanks for the time and effort on making this.

Now, for the bug:

When defining a base 256 color as 0 (code for terminal black) with Color and then setting a highlight to it, it gets ignored.

# Color name         GUI        Base256    Base16 (optional)
Color: black         #000000    0          Black

# Group              Foreground        Background        Attributes
EndOfBuffer          black             none

The generated colorscheme ignores the foreground color. The highlight group on the s:t_Co >= 256 section looks like this:

  hi EndOfBuffer ctermbg=NONE cterm=NONE

Probably 0 being evaluated as false somewhere?

Minimum working example:

# vim: ft=colortemplate
Full name:  Black Foreground Test
Short name: blackfg
Author:     Me <[email protected]>

Variant:    256
Background: dark

# Color palette
Color:      black  #000000 0 Black
Color:      white  #ffffff 7 White

# Highlight group definitions
Normal white none
EndOfBuffer black none
# Etc…

Is compiled to:

" Name:         Black Foreground Test
" Author:       Me <[email protected]>
" Maintainer:   Me <[email protected]>
" License:      Vim License (see `:help license`)
" Last Updated: Wed Aug 26 17:35:08 2020

" Generated by Colortemplate v2.0.0

set background=dark

hi clear
if exists('syntax_on')
  syntax reset
endif

let g:colors_name = 'blackfg'

let s:t_Co = exists('&t_Co') && !empty(&t_Co) && &t_Co > 1 ? &t_Co : 2

if s:t_Co >= 256
  hi Normal ctermfg=7 ctermbg=NONE cterm=NONE
  hi EndOfBuffer ctermbg=NONE cterm=NONE      <--------------------------------
  unlet s:t_Co
  finish
endif

" Background: dark
" Color:      black  #000000 0 Black
" Color:      white  #ffffff 7 White
" vim: et ts=2 sw=2

The highlighted line should be compiled to:

  hi EndOfBuffer ctermfg=0 ctermbg=NONE cterm=NONE

Include is not colortemplateKey

Shouldn't Include: be a colortemplateKey?

Add airline support

(Original issue from @jordwalke at #2)

Should this template include vim-airline support?

Feature request: parse error when link target contains multiple tokens

I made a mistake of using the link syntax (->) for a plain highlight defintion. E.g.

myHighlight -> red none
# instead of
myHighlight red none

It would be nice for this to get caught at build time.

Thanks

Colors not recognized in Nvim

I installed the package with Plug in .config/nvim/plugged, and when I compile the default dark.colortemplate with :Colortemplate! ~/.config/nvim this comes up:

colortemplate.txt

It does not happen in Vim or GVim so it's Nvim specific

Rendering glitches in Neovim

I always found it strange that no one else had created an issue so I can only assume that I'm the only one plagued by this. But I have very strange rendering glitches where e.g., a single line is suddenly repeated for each line I scroll downwards.

I've had this for as long as I can remember. I'm on Neovim

NVIM v0.5.0-dev
Build type: Release
LuaJIT 2.1.0-beta3
Compilation:
Compiled by nixbld1

Features: +acl +iconv +tui
See ":help feature-compile"

   system vimrc file: "$VIM/sysinit.vim"
  fall-back for $VIM: "
/nix/store/vglb2f345siggaxdai8ghlnjx4y428an-neovim-unwrapped-master/share/nvim
"

Run :checkhealth for more info

and here are my settings

set shell=bash
" https://www.reddit.com/r/vim/comments/25g1sp/why_doesnt_vim_syntax_like_my_shell_files/
let g:is_posix = 1

set wildignore+=*/.git/*,
            \tags,
            \*/node_modules/*,
            \*/build/*,
            \*/dist/*,
            \*/compiled/*,
            \*/tmp/*
set cmdheight=2
set diffopt=algorithm:patience,filler,iwhiteall,indent-heuristic
set expandtab
set fillchars=stl:\ ,vert:\|,fold:\ 
set grepprg=rg\ --vimgrep\ --no-heading\ --smart-case
set hidden
set ignorecase
set noshowmode
set updatetime=100
set list
set listchars=tab:»\ ,extends:›,precedes:‹,nbsp:·,trail:·
set inccommand=split
set nocursorline
set nonumber
set path-=/usr/include
set shiftwidth=4
set shortmess+=c
set smartcase
set splitbelow
set splitright
set completeopt-=preview
set termguicolors
set undofile

" Automatically resize windows if host window changes (e.g., creating a tmux
" split)
augroup Resize
    autocmd!
    autocmd VimResized * wincmd =
augroup END
" }}}

Using terminal's default fg and bg in 16/8-color variant

First, thanks for making this great toolkit! Very nice :-)

I'm working on colortemplate for selenized and there's one thing I'm missing: being able to define a Color that will use terminal's default background (or foreground) when used in 16/8-color mode. Currently color definitions can specify only one of 16 ANSI colors, but actually all terminals have a separate setting for foreground and background color. (I.e. default background doesn't have to be the same as ANSI black).

Here's a minimal example:

# vim: ft=colortemplate
Full name:  background and foreground test
Short name: bg_fg_test
Author:     JW <[email protected]>

Background: dark

# Color palette
Color:      bg_grey #181818 ~ Black  # I'd like to say "bg" or "none" here,
Color:      fg_grey #b9b9b9 ~ White  # but it throws an error

# Highlight group definitions
Variant:    gui 256 8
Normal fg_grey bg_grey

Combined with terminal palette defined like this:

bg: #181818
black: #3b3b3b
br_black: #626262
white: #8c8c8c
fg: #b9b9b9
br_white: #e7e7e7
...

Which means that it looks as follows:

The result in terminal Vim is different than in GUI Vim:

(background in terminal vim is 3b3b3b while it should be 181818, foreground is e7e7e7 while it should be b9b9b9).

I've been able to work around this with something like this, but it's a bit lame...

# vim: ft=colortemplate
Full name:  background and foreground test
Short name: bg_fg_test
Author:     JW <[email protected]>

Background: dark

# Color palette
Color:      bg_grey #181818 ~ Black
Color:      fg_grey #b9b9b9 ~ White

# Highlight group definitions
Variant:    gui 256
Normal fg_grey bg_grey

Variant:    8
Normal none none

Great idea.

This is a great idea. Here's a couple of suggestions/ideas.

• You might take a look at @xolox's comment here about some known issues with colorscheme switching. If creating a template for other plugins to be based on, there might be some problems with colorscheming you can fix at the template level.
• Should this template include vim-airline support?