-
Notifications
You must be signed in to change notification settings - Fork 23
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
Toggling 'termguicolors' changes the colorscheme #54
Comments
'termguicolors'
changes the colorscheme back to default'termguicolors'
changes the colorscheme
'termguicolors'
changes the colorscheme
Confirmed with 8.2.2164 in iTerm (true colors) and Terminal (not true colors) on macOS. Thank you for spotting this. |
Well, that is by design. Color schemes generated by Colortemplate are optimized so that they only define the attributes that apply to the current environment. That is to say, if @romainl has already criticized this approach (I can't find the discussion right now, but it might be useful to link it here), and I have promised to address this in Colortemplate: once that is done, rebuilding the color schemes would fix this (no change in the templates will be necessary). Life is getting in the way in this period, but I'll try to use some weekends to work on that. |
I wanted to check that the color scheme with and without |
for now you can just reapply the same colorscheme after changing termguicolors PS. But you know this, as far as I can see (missed it from your post) |
Hi @lifepillar, is there anything from your side on this? |
I am not planning to address this in Colortemplate v2, as I don't think it is a high (or even medium) priority issue (I don't see compelling use cases for changing Colortemplate v3 (which is not published yet—but I am working on it) will provide more flexibility in the generated code, and will fix this. |
Thanks for the update, @lifepillar! @romainl would we wait for v3 before asking Bram and team to checkout what we have? |
Vimmers have been living with broken colorschemes for decades so they can probably accept that |
Note that I have no ETA for v3 yet. The new version will be a complete rewriting in Vim9 script, but the template's syntax won't change, at least not in a way that will affect this project—e.g., it most likely won't support a The main advantages of v3 will (hopefully) be speed and a better (and I hope smaller) code base. The generated output will change in a way that will fix this issue, or it will be possible to choose between different “optimization levels” for the generated code: I will ask for feedback when I am ready to ship a usable version. So, if you feel that the color schemes are now up to date (you have been doing a great job btw!), IMO definitely go ahead and send them to Bram. I think it won't be a problem to send further improvements later on, as with other parts of the runtime. |
I sometimes start vim, editing a file, and later realize this will be a longer editing session and I want to have my terminal back during that session without jumping in and out of vim or suspending it all the time, so i type ":gui" to continue working on the file. I suggest adding something like this: |
Ok, this has come up a few times already… I was not aware of So, the solution here is to build the color schemes so that GUI and terminal definitions are both applied, regardless of the values of |
Well, there's also the case of Vim honouring IMO…
|
For the last 2 we have to create issues against vim repo I guess |
Some users have complained that setting `termguicolors` *after* loading the color scheme does not make GUI colors immediately available: rather, reloading the color scheme is required. Initially, I thought that there was no sensible use case for setting `termguicolors` after loading a color scheme, but that is not the case apparently. The most compelling reason for having GUI colors defined in all sufficiently capable terminals is Vim's `:gui` command. This is what user jeanluc2020 reported [here](vim/colorschemes#54): >I sometimes start vim, editing a file, and later realize this will be >a longer editing session and I want to have my terminal back during that >session without jumping in and out of vim or suspending it all the time, >so i type ":gui" to continue working on the file. This commit implements a quick fix that should solve this issue. This solution is suboptimal, however, because `gui` and `cterm` definitions are still kept separate. Ideally, one would want to define each highlight group only once. But then, is it necessary to define `cterm` attributes when running in the GUI?
Some users have complained that setting `termguicolors` *after* loading the color scheme does not make GUI colors immediately available: rather, reloading the color scheme is required. Initially, I thought that there was no sensible use case for setting `termguicolors` after loading a color scheme (except for testing purposes), but that is not the case apparently. The most compelling reason for having GUI colors defined in all terminals is Vim's `:gui` command. This is what user jeanluc2020 reported [here](vim/colorschemes#54): >I sometimes start vim, editing a file, and later realize this will be >a longer editing session and I want to have my terminal back during that >session without jumping in and out of vim or suspending it all the time, >so i type ":gui" to continue working on the file. This commit addresses this issue by defining GUI colors unconditionally in all environments; cterm and term attributes are instead defined according to the value of t_Co, as usual.
The current Colortemplate's master fixes this issue. As proposed by @romainl, |
Regarding |
@lifepillar in theory yes, as it is supposed to be a harmless, passive, global variable. But I found out recently that, at least in some builds, attempts were made by Vim to interpret those colors in situations where it shouldn't, leading to unexpected results. For that reason I would suggest putting
This is what I have in Apprentice:
With that guard in place and the gui attributes set unconditionally, we should be good. |
@jeanluc2020 If you have time, could you try again with the master branch? |
Thanks, looks much better now, switching from vim inside an xterm to gvim via :gui now works perfectly. |
Or perhaps, vim/vim@b2b3acb did fix it? |
@lifepillar I can't reproduce the bug either so it must have been fixed. |
Steps to reproduce bugs
This affects most (all?) the remade colorschemes but not the original ones.
Vim version: 8.2.2488
Terminal: Konsole
OS: Kubuntu 20.10
The text was updated successfully, but these errors were encountered: