lifepillar / vim-colortemplate Goto Github PK
View Code? Open in Web Editor NEWThe Toolkit for Vim Color Scheme Designers!
The Toolkit for Vim Color Scheme Designers!
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).
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.
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
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:
simplest fix seems this (putting set bg
at the end of the scheme)
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.
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:
If you like this idea, or have any questions, please give me some feedback!
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.
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
" }}}
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
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
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"
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.
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:
It does not happen in Vim or GVim so it's Nvim specific
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:
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 😉
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.
Hi,
I recently found myself in a situation in which I needed to pass parameters to an Include
d 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.
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.
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.
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:
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,1
is darkred
, etc.There is no difference between 1
and 0
.
This is a great idea. Here's a couple of suggestions/ideas.
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).
reproduce:
thx.
Using vim-commentary I get deprecated comments #
instead of ;
.
vim/vim#10133 adds a new highlight group, CurSearch
.
Related: vim/colorschemes#159
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
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.
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?
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.
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
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 between0
and87
. 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.
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
I cannot reproduce this on vim (where exists('*appendbufline') == 1
)
(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.
Reproduction steps:
:Colortemplate!
b #
back to templateb #
back to generated colorscheme, but it's now an unlisted bufferb #
back to template:Colortemplate!
fails with error E94Is it really needed to delete the buffer? At least using :bwipeout
this wouldn't happen.
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?
term=
/t=
and make it only apply to the final term=
.cterm=
/c=
to handle color terminals explicitly.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
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
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
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.
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
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
.
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).
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
It would be great for converting manually-created colorschemes to colortemplate if colortemplate had a command to generate your initial template.
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.
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 unset
ting 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.
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.
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.
(Original issue from @jordwalke at #2)
Should this template include vim-airline support?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.