[vim/vim] Change Vim's terminal colors when termguicolors is set (#2353)
Lifepillar
While I have no problems with Vim's terminal colors with notermguicolors, when termguicolors is set the terminal always uses a default palette. For example, these are the ANSI colors in iTerm2 when both iTerm2's ANSI colors and Vim's colorscheme are set to Solarized:
The same with MacVim (and, I guess, with any gVim). Is there a way yet to change those colors? I have only been able to change the background through the Terminal highlight group. Perhaps, there should be TerminalBlack, TerminalRed, and so on?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
Bram Moolenaar
Lifepillar wrote:
> While I have no problems with Vim's terminal colors with
> uses a default palette. For example, these are the ANSI colors in
> iTerm2 when both iTerm2's ANSI colors and Vim's colorscheme are set to
> Solarized:
>
>
> The same with MacVim (and, I guess, with any gVim). Is there a way yet
> to change those colors? I have only been able to change the background
> through the `Terminal` highlight group. Perhaps, there should be
Well, the idea is that you have already set terminal colors for use with
Vim, and that's what you will get in the terminal window. Once you have
something running there, you can change the colors inside it. E.g.,
when running Vim you can have that one use different colors (so that you
don't get confused about Vim running in a terminal window inside Vim).
((Could get worse, I was debugging Vim running the terminal debugger
plugin in a Vim using the terminal debugger in Vim...))
--
hundred-and-one symptoms of being an internet addict:
15. Your heart races faster and beats irregularly each time you see a new WWW
site address in print or on TV, even though you've never had heart
problems before.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
Lifepillar
Well, the idea is that you have already set terminal colors for use with Vim
I'm not sure I understand. Do you mean my OS's terminal colors?
and that's what you will get in the terminal window.
When termguicolors is set (or in GUI Vim), the colors of my OS's terminal are not the colors I get in Vim's terminal window, except for the background (see screenshot in my previous post). Which is not surprising to me: at least in GUI Vim, which colors could Vim choose?
The main problem is that such colors are not always clearly visible against the background (in the example above, Solarized's background). I know that I can set the attributes of the Terminal highlight group to change the background. But my question is: can I change the remaining 15 colors instead?
For example, NeoVim has g:terminal_color_NN variables for that purpose.
Bram Moolenaar
Lifepillar wrote:
> >Well, the idea is that you have already set terminal colors for use with Vim
>
> I'm not sure I understand. Do you mean my OS's terminal colors?
>
> >and that's what you will get in the terminal window.
>
> When `termguicolors` is set (or in GUI Vim), the colors of my OS's
> for the background (see screenshot in my previous post). Which is not
> surprising to me: at least in GUI Vim, which colors could Vim choose?
used to do something else.
> The main problem is that such colors are not always clearly visible
> against the background (in the example above, Solarized's background).
> I know that I can set the attributes of the `Terminal` highlight group
> to change the background. But my question is: can I change the
> remaining 15 colors instead?
colors, in which case you can't chose others. Or 256 or more colors are
supported, in which case the program running in the terminal can use
them.
> For example, NeoVim has `g:terminal_color_NN` variables for that
> purpose.
I know that some terminals allow redefining the first 16 colors, but
that usually leads to lots of confusion and endless tuning, since no
program knows what to do.
I wonder, if not running the program in a Vim terminal window, do you
start a new terminal, with different color settings, to run that
program?
--
hundred-and-one symptoms of being an internet addict:
Lycos.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Lifepillar
I haven't explained myself well, sorry. I am talking about the 16 ANSI colors that most terminals support and allow redefining. I am always running Vim in an environment that has at least 256 colors. In what follows, I assume that I am running Vim in an environment supporting millions of colors (i.e., a true-color terminal or a GUI version of Vim).
If I use a terminal and set notermguicolors, when I open a terminal window inside Vim—say, with a Bash shell—such shell inherits the 16 ANSI colors from the OS's terminal. So, a shell in my OS's terminal and a shell inside a Vim terminal window look the same. So far, so good.
If I set termguicolors, when I open a terminal window inside Vim, such window has its background set to Normal, but it uses a default 16-color palette independent of my OS's terminal settings.
For example, the following is a Vim terminal window, with notermguicolors and the Solarized 8 colorscheme, running in iTerm2 whose 16-color palette is set to Solarized, too:
And this is the same configuration, but with termguicolors set:
Note that, in this case, the shell does not use the Solarized palette.
NeoVim has 16 variables g:terminal_color_0 through g:terminal_color_15, to set Vim's terminal 16-color palette using GUI colors (e.g., let g:terminal_color_0 = '#404040').
Bram Moolenaar
Lifepillar wrote:
> I haven't explained myself well, sorry. I am talking about the 16 ANSI
> colors that most terminals support and allow redefining. I am always
> running Vim in an environment that has at least 256 colors. In what
> follows, I assume that I am running Vim in an environment supporting
> millions of colors (i.e., a true-color terminal or a GUI version of
> Vim).
>
> window inside Vim—say, with a Bash shell—such shell inherits the 16
> ANSI colors from the OS's terminal. So, a shell in my OS's terminal
> and a shell inside a Vim terminal window look the same. So far, so
> good.
>
> such window has its background set to `Normal`, but it uses a default
> 16-color palette independent of my OS's terminal settings.
default 16-color palette. But we can convert this back to the original
16-color number, this happens in color2index(). But when Vim is using
256 or more colors, we use a lookup table color_numbers_256[] that uses
some of the >16 colors to get a better palette.
So it should work OK, if you set t_Co to 16 in Vim and disable
'termguicolors'. Can you try that? Then the program running in the
terminal window should use the right 16 colors (but colors outside of
those 16 may be wrong).
> For example, the following is a Vim terminal window, with
> `notermguicolors` and the Solarized 8 colorscheme, running in iTerm2
> whose 16-color palette is set to Solarized, too:
>
>
> And this is the same configuration, but with `termguicolors` set:
>
>
> Note that, in this case, the shell does not use the Solarized palette.
>
> NeoVim has 16 variables `g:terminal_color_0` through
> GUI colors (e.g., `let g:terminal_color_0 = '#404040'`).
have it work out-of-the-box.
What would work is to ignore 'termguicolors' for the first 16 colors.
However, that's after converting RGB back to the color number, thus this
may fail.
I think we can only properly solve this by changing libvterm, it must
return the color number instead of RGB (or return both).
--
hundred-and-one symptoms of being an internet addict:
only by a 17" inch svga monitor.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
Lifepillar
So it should work OK, if you set t_Co to 16 in Vim and disable 'termguicolors'. Can you try that?
All is fine when termguicolors is disabled. My issue is specifically with termguicolors set, and with the first 16 colors only.
What would work is to ignore 'termguicolors' for the first 16 colors.
When Vim runs within a GUI (e.g., MacVim), which colors should a terminal window display then?
vim-dev ML
> >So it should work OK, if you set t_Co to 16 in Vim and disable 'termguicolors'. Can you try that?
>
> All is fine when `termguicolors` is disabled. My issue is specifically with `termguicolors` set, and with the first 16 colors only.
>
> >What would work is to ignore 'termguicolors' for the first 16 colors.
>
> When Vim runs within a GUI (e.g., MacVim), which colors should a terminal window display then?
>
> https://github.com/vim/vim/issues/2353#issuecomment-346104155
I observe the same behaviour (on linux, gnome terminalxtermx), and
indeed when setting t_Co=16 and notermguicolor the first 16 colors are
the right ones. It would be nice indeed to have a solution for
termguicolors and t_Co=256.
Best regards,
Marcin
Bram Moolenaar
Lifepillar wrote:
> >So it should work OK, if you set t_Co to 16 in Vim and disable 'termguicolors'. Can you try that?
>
> All is fine when `termguicolors` is disabled. My issue is specifically
> with `termguicolors` set, and with the first 16 colors only.
>
> >What would work is to ignore 'termguicolors' for the first 16 colors.
>
> When Vim runs within a GUI (e.g., MacVim), which colors should a
> terminal window display then?
expect the user to setup Vim (colorschme) to work well in this terminal.
We can assume other programs also work well, either by default or are
configued that way. So when opening a terminal inside Vim, the same
thing should happen.
If Vim is able to decode the values from libvterm, knowing it is using
the 16 ANSI colors, they can be passed to the underlaying terminal
as-is, and the right color should show up. Currently, when
'termguicolors' is on, then we always use the RGB values, and these are
likely different from what the terminal would show for these colors.
I'm discussing with Paul Evans if libvterm can return the color index,
so that Vim doesn't need to decode the RGB values. When using
'termguicolors' that won't be reliable.
--
How To Keep A Healthy Level Of Insanity:
5. Put decaf in the coffee maker for 3 weeks. Once everyone has gotten
over their caffeine addictions, switch to espresso.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
You are receiving this because you commented.
Andy Massimino
Is there any possibility of this being addressed for the 8.1 release?
There's no way to adjust the ansi colors used in a :terminal in Gvim or when using termguicolors. I've resorted to changing the values in the ansi_colors table in src/libvterm/src/pen.c.
I understand the motivation for using the same colors as the underlying terminal, but this still leaves GVim out since there's no parent terminal. Generally, it would be nice if the RGB colors were configurable, if the user chooses to deviate from libvterm's defaults. This is necessary with many vim colorschemes, since the libvterm colors are difficult to read against certain backgrounds.
—
You are receiving this because you commented.
Bram Moolenaar
Andy Massimino wrote:
> Is there any possibility of this being addressed for the 8.1 release?
>
> There's no way to adjust the ansi colors used in a `:terminal` in Gvim
> in the `ansi_colors` table in `src/libvterm/src/pen.c`.
>
> I understand the motivation for using the same colors as the
> underlying terminal, but this still leaves GVim out since there's no
> parent terminal. Generally, it would be nice if the RGB colors were
> configurable, if the user chooses to deviate from libvterm's defaults.
> This is necessary with many vim colorschemes, since the libvterm
> colors are difficult to read against certain backgrounds.
colors, we should recognize that and use the specified colors instead of
the 16 ANSI colors that Vim uses itself? It would only work if Vim
supports RGB colors, thus in the GUI or with 'termguicolors' set.
I suppose we could check if any of the ANSI colors is at a non-default
value. Or do this per color. Both have flaws. Would a program
normally only change one or two colors (e.g. foreground and background)
and expect the others to remain at their default? Or would that mean
all the colors that libvterm has should be used?
--
You have heard the saying that if you put a thousand monkeys in a room with a
thousand typewriters and waited long enough, eventually you would have a room
full of dead monkeys.
(Scott Adams - The Dilbert principle)
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
You are receiving this because you commented.
chdiza
This is necessary with many vim colorschemes, since the libvterm colors are difficult to read against certain backgrounds
Indeed, on macOS they're unusably difficult to read whenever the background is black or nearly so. This by itself is sufficient to make the :terminal feature worthless to me personally.
—
You are receiving this because you commented.
Andy Massimino
so when a program running in a terminal window changes the ANSI colors
Sorry, I'm not sure I fully follow. As far as I know, it's not possible for a program running in a terminal window to change the RGB values of the ANSI color palette since libvterm does not support the OSC 4 code for this. If a program uses the basic 8 or 16 ANSI colors, the expectation is that the user has already set up their terminal to their preference- the exact RGB values of these colors are not standardized between terminals so there's no consistency guarantee.
use the specified colors instead of the 16 ANSI colors that Vim uses itself
Yes, but I think it doesn't matter with GUI/termguicolors, since when does a GUI user ever see Vim's built-in 16 ANSI colors? Besides, how does one configure the 16 ANSI colors that GVim uses, as displayed in syntax/colortest.vim? Perhaps Vim's built-in 16 colors could be configured along with libvterm's 16 colors, but there is also little harm if they are distinct.
Or would that mean all the colors that libvterm has should be used?
What I am suggesting is give the Vim user the ability to use do some action or set some option which calls vterm_state_set_palette_color to change the RGB codes that libvterm knows the ANSI colors by. I am aware this would only work for GUI/termguicolors. A terminal+notermguicolors user would continue to see their normal terminal colors.
—
You are receiving this because you commented.
Bram Moolenaar
Andy Massimino wrote:
> > so when a program running in a terminal window changes the ANSI colors
>
> Sorry, I'm not sure I fully follow. As far as I know, it's not
> possible for a program running in a terminal window to change the RGB
> values of the ANSI color palette since libvterm does not support the
> OSC 4 code for this. If a program uses the basic 8 or 16 ANSI colors,
> the expectation is that the user has already set up their terminal to
> their preference- the exact RGB values of these colors are not
> standardized between terminals so there's no consistency guarantee.
by calling vterm_state_set_palette_color().
Xterm has default colors which function as a reference. I made libvterm
use the same colors. However, with xterm they can be overruled with X
resources.
> > use the specified colors instead of the 16 ANSI colors that Vim uses itself
>
> Yes, but I think it doesn't matter with GUI/termguicolors, since when
> does a GUI user ever see Vim's built-in 16 ANSI colors? Besides, how
> does one configure the 16 ANSI colors that GVim uses, as displayed in
> syntax/colortest.vim? Perhaps Vim's built-in 16 colors could be
> configured along with libvterm's 16 colors, but there is also little
> harm if they are distinct.
>
> > Or would that mean all the colors that libvterm has should be used?
>
> What I am suggesting is give the Vim user the ability to use do some
> action or set some option which calls `vterm_state_set_palette_color`
> to change the RGB codes that libvterm knows the ANSI colors by. I am
> aware this would only work for GUI/termguicolors. A
> terminal+notermguicolors user would continue to see their normal
> terminal colors.
able to define the 16 ANSI colors that libvterm is using. Looks like we
don't need more than that.
--
hundred-and-one symptoms of being an internet addict:
and a laptop.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
You are receiving this because you commented.
Antoine
As @lifepillar said, neovim terminal handles colors properly out of the box.
I did not have to set the g:terminal_color_ myself, everything was done automatically.
I don't know how they did it, but could Vim handle terminal colors the same way ?
—
You are receiving this because you commented.
Bram Moolenaar
What do you mean with "properly"? Please give a reproducible example. And without using iTerm2, I don't have that.
—
You are receiving this because you commented.
Antoine
@brammool , first my mistake, g:terminal_color_ are actually set by gruvbox (my colorscheme plugin).
Then here is the minimal .vimrc to reproduce the different behaviors:
call plug#begin('~/.vim/plugins_by_vimplug') Plug 'morhetz/gruvbox' call plug#end() set termguicolors colorscheme gruvbox
I used gnome-terminal on Ubuntu 16.04.
Here is what ls --color=auto looks on vim:
Here is what ls --color=auto looks on neovim:
Maybe setting extra variable is not the right approach, but if it is, would it be possible to keep the same naming convention as in neovim ?
More and more features are slightly different between vim and neovim (terminal, jobs etc) and it makes it harder and harder for users and plug-in developers to support both editors.
Thanks a lot !
—
You are receiving this because you commented.
Bram Moolenaar
Antoine wrote:
> @brammool , first my mistake, ```g:terminal_color_``` are actually set by ``gruvbox`` (my colorscheme plugin).
>
> Then here is the minimal .vimrc to reproduce the different behaviors:
> call plug#begin('~/.vim/plugins_by_vimplug')
> Plug 'morhetz/gruvbox'
> call plug#end()
>
> set termguicolors
> colorscheme gruvbox
> ```
>
> I used gnome-terminal on Ubuntu 16.04.
> Here is what ```ls --color=auto``` looks on vim:
> Here is what ```ls --color=auto``` looks on neovim:
>
> Maybe setting extra variable is not the right approach, but if it is,
> would it be possible to keep the same naming convention as in neovim ?
bad choice.
> More and more features are slightly different between vim and neovim
> (terminal, jobs etc) and it makes it harder and harder for users and
> plug-in developers to support both editors.
They made their own design choices and haven't discussed them on
vim-dev, so it's no surprise diversion happens.
--
hundred-and-one symptoms of being an internet addict:
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
You are receiving this because you commented.
Justin M. Keyes
>
> Antoine wrote:
>
>> @brammool , first my mistake, ```g:terminal_color_``` are actually set by
>> ``gruvbox`` (my colorscheme plugin).
>>
>> Then here is the minimal .vimrc to reproduce the different behaviors:
>> ```vim
>> call plug#begin('~/.vim/plugins_by_vimplug')
>> Plug 'morhetz/gruvbox'
>> call plug#end()
>>
>> set termguicolors
>> colorscheme gruvbox
>> ```
>>
>> I used gnome-terminal on Ubuntu 16.04.
>> Here is what ```ls --color=auto``` looks on vim:
>>
>> 
>> Here is what ```ls --color=auto``` looks on neovim:
>>
>> 
>>
>> Maybe setting extra variable is not the right approach, but if it is,
>> would it be possible to keep the same naming convention as in neovim ?
>
> As mentioned in the other message, using global variables looks like a
> bad choice.
group names like TermColor1, TermColor2, for each of the color
indices.
>> More and more features are slightly different between vim and neovim
>> (terminal, jobs etc) and it makes it harder and harder for users and
>> plug-in developers to support both editors.
>
> Neovim is a fork, thus they should follow Vim, if they so desire.
> They made their own design choices and haven't discussed them on
> vim-dev, so it's no surprise diversion happens.
names of job*() functions were chosen in analogy with buf*()
functions, observing that the old buffer_exists(), buffer_name(), etc.
were deprecated. But then Vim decided to add underscores again for no
apparent reason. Not to mention, Vim's jobs API is arbitrarily
different, it isn't meaningfully different, so it is incompatible
merely on a whim with conventions that had already been established 2
years earlier by Nvim.
The name of TermOpen was discussed in:
https://groups.google.com/d/msg/vim_dev/c5uBCS-_QyI/S15G3mG5AgAJ
where Nikolai cited evidence that there's no consistent choice of
"term" or "terminal".
But you ignored the discussion, and named the event TerminalOpen,
anyway, which again adds entropy for no reason.
---
Justin M. Keyes
vim-dev ML
Bram Moolenaar
Justin M. Keyes wrote:
> >> More and more features are slightly different between vim and neovim
> >> (terminal, jobs etc) and it makes it harder and harder for users and
> >> plug-in developers to support both editors.
> >
> > Neovim is a fork, thus they should follow Vim, if they so desire.
> > They made their own design choices and haven't discussed them on
> > vim-dev, so it's no surprise diversion happens.
>
> Neovim project did try to follow Vim's own conventions. For example,
> names of job*() functions were chosen in analogy with buf*()
> functions, observing that the old buffer_exists(), buffer_name(), etc.
> were deprecated. But then Vim decided to add underscores again for no
> apparent reason. Not to mention, Vim's jobs API is arbitrarily
> different, it isn't meaningfully different, so it is incompatible
> merely on a whim with conventions that had already been established 2
> years earlier by Nvim.
>
> The name of TermOpen was discussed in:
>
> https://groups.google.com/d/msg/vim_dev/c5uBCS-_QyI/S15G3mG5AgAJ
>
> where Nikolai cited evidence that there's no consistent choice of
> "term" or "terminal".
>
> But you ignored the discussion, and named the event TerminalOpen,
> anyway, which again adds entropy for no reason.
And decided that TerminalOpen was a better name.
There are many things in Neovim that are similar, but not exactly the
same. Using a same name would then be confusing. I believe this
applies to the job functions. Better get an error right away when using
a function that's different, than having to figure out what subtle
difference is causing a problem.
Different people have different opinions, that's life.
--
hundred-and-one symptoms of being an internet addict:
you are pretending to catch your breath.
/// Bram Moolenaar -- Br...@Moolenaar.net -- http://www.Moolenaar.net \\\
/// sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ \\\
\\\ an exciting new programming language -- http://www.Zimbu.org ///
\\\ help me help AIDS victims -- http://ICCF-Holland.org ///
—
You are receiving this because you commented.
Dennis B
There is a need for Vim 8 terminal colors 1 to 16 to be user definable. It is especially important for those of us who maintain Vim colorschemes.
The color issue is most pronounced in MacVim and gVim which are GUI programs and hence can not inherit any terminal colors. For instance FZF.vim, which now uses Vim 8 terminal, looks especially bad due to the default terminal colors chosen by MacVim and gVim. Allowing terminal color overides, like Neovim already provides, would solve the issue.
New highlight group names like TermColor1, TermColor2, etc makes sense as noted by @vim-ml.
—
You are receiving this because you were mentioned.