Tweaking t_Co to configure colorscheme

classic Classic list List threaded Threaded
2 messages Options
Reply | Threaded
Open this post in threaded view
|

Tweaking t_Co to configure colorscheme

Lifepillar-2
I have made some colorschemes that use colors 0-15 or 16-256 according to the
value of t_Co or based on a user option:

    if &t_Co < 256 || g:mytheme_force16colors = 1
      # Define hi groups with colors 0-15
    else
      # Define hi groups with colors 16-256
    endif

Setting t_Co at runtime appears to cause the colorscheme to reload, so it seems
that the user option above is redundant. Is there any reason why one should
avoid changing t_Co at runtime or is it ok to set t_Co to reload the
colorscheme with a different configuration?

Thanks,
Life.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.
Reply | Threaded
Open this post in threaded view
|

Re: Tweaking t_Co to configure colorscheme

Tony Mechelynck
On Tue, Apr 30, 2019 at 11:22 PM 'Lifepillar' via vim_use
<[hidden email]> wrote:

>
> I have made some colorschemes that use colors 0-15 or 16-256 according to the
> value of t_Co or based on a user option:
>
>     if &t_Co < 256 || g:mytheme_force16colors = 1
>       # Define hi groups with colors 0-15
>     else
>       # Define hi groups with colors 16-256
>     endif
>
> Setting t_Co at runtime appears to cause the colorscheme to reload, so it seems
> that the user option above is redundant. Is there any reason why one should
> avoid changing t_Co at runtime or is it ok to set t_Co to reload the
> colorscheme with a different configuration?
>
> Thanks,
> Life.

Well, the only reason I can imagine of having to set t_Co at runtime
would be because a badly set $TERM causes t_Co to be set to something
else than what the terminal actually supports. In that case the right
place to change t_Co would be in the vimrc, before loading any
colorscheme. For instance, on my system AFAIK all terminals support
256 colors _except_ the text-only Linux console (Ctrl-Alt-F2 or
similar) so my vimrc includes the following:

" set many-colors mode on terminals other than the Linux console
if !has('gui_running') && &term !~# "^linux" && &t_Co <=16
  set t_Co=256
endif

Other than that, I don't touch t_Co. The reason I test "&& &t_Co <=
16" is that if some terminal has a $TERM setting resulting in, say, a
t_Co of 88, then that's probably correct.

Now in you find out in the middle of a Vim session that t_Co is set to
a wrong value, you can probably set it then manually with no ill
effects, or at least nothing worse than what you were already having,
i.e., wrong display colors. After that, you may or may not (I'm not
sure) have to reload your colrscheme.

Best regards,
Tony.

--
--
You received this message from the "vim_use" maillist.
Do not top-post! Type your reply below the text you are replying to.
For more information, visit http://www.vim.org/maillist.php

---
You received this message because you are subscribed to the Google Groups "vim_use" group.
To unsubscribe from this group and stop receiving emails from it, send an email to [hidden email].
For more options, visit https://groups.google.com/d/optout.