-
Notifications
You must be signed in to change notification settings - Fork 164
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
Invalid expression #60
Comments
This seems to be a bug of vim, I don't know how to fix it in color scheme level. But I found some solutions here: joshdick/onedark.vim#110 |
Thanks for the link. Manually calling I suppose one solution is to move required functions from A much more drastic approach could be to use something like https://github.com/lifepillar/vim-colortemplate or https://github.com/romainl/vim-rnb that generates the colors from a template. That would remove the need for functions to begin with. And with the bonus of reducing the load time because it wouldn't have to call hundreds of functions. This would probably involve significant work though. |
Some explanations:
In fact, this color scheme used to use color template in the earlier stage, but I finally decided to switch to pure vim script because there is a very serious disadvantage in color template: you can't change the color palette once the color scheme file is generated. Let see how many color schemes files we need to generate if using color template: 3 palettes (material, mix, original) * 3 contrast options (hard, medium, soft) * 2 background options (light, dark) = 18 This is the main reason I decided to switch to pure vim script. Currently, this color scheme uses a single variable Another advantage to use a variable to control the color palette is that it's easier to change the colors. For example, I'm using the original palette but I don't like the green color Another practice is that you can even use a completely different color palette from some other color schemes. For example, gruvbox-material/doc/gruvbox-material.txt Lines 406 to 446 in 2ba842e
Well, so you've understood why I choose to use pure vim script to rewrite this color scheme instead of using color template, then there's an emerging problem: since too many file types and plugins are optimized in this color scheme, the performance is getting very bad compared to using color template. So I decided to add a new option But the optimization code of some file types requires This is why the autoload file is required. |
Thanks for the explaining your decisions! Makes sense I guess given the many permutations and complexity. Though I suspect some of the issues could be solved by using conditionals and includes, at least with lifepillar/vim-colortemplate. See https://github.com/lifepillar/vim-solarized8 which is quite complex. The part about the plugins (lightline, airline etc) is valid though. Not sure how to make that work in a nice way.
I'm not convinced by this. I get doing minor tweaks, but if I swap the color palette completely, why would I use this colorscheme to begin with? It's no longer gruvbox-material at that point. Anyway, I'll close this since the issue can be solved by following the tips in joshdick/onedark.vim#110. Thanks! |
You can checkout the earlier commits, I tried that, and it's complex indeed.
Yes, this is just my personal preference. As I said in the doc, there are some bugs in soft-era and I just don't want to maintain a fork, so I use this variable to get a more usable one (IMO), and I mentioned this practice simply in order to point out that possibility. Anyway, I don't encourage anyone else to do this. |
That's fair 🙂 |
echo $TERM
: xterm-kittyvim --version
: 8.2.2100Minimal vimrc that can reproduce this bug
Steps to reproduce this bug using minimal vimrc
Install gruvbox-material using the native package manager (
:h packages
) and then start Vim:Actual behaviour
Loads of errors (see above). Note that this is only a problem in Vim, not in Neovim.
Expected behaviour
Start without errors.
The text was updated successfully, but these errors were encountered: