[RFC] tui: Add support for true color terminals #2198

Merged
merged 1 commit into from Mar 20, 2015

Conversation

Projects
None yet
9 participants
@tarruda
Member

tarruda commented Mar 19, 2015

This is enabled by setting the $NVIM_TUI_ENABLE_TRUE_COLOR environment variable, eg:

$ NVIM_TUI_ENABLE_TRUE_COLOR=1 nvim

Close #59

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Mar 19, 2015

Member

For anyone wondering, mintty does not support true color: https://code.google.com/p/mintty/issues/detail?id=431

And here's a comprehensive list of true color support across terminals:

https://gist.github.com/XVilka/8346728

Member

justinmk commented Mar 19, 2015

For anyone wondering, mintty does not support true color: https://code.google.com/p/mintty/issues/detail?id=431

And here's a comprehensive list of true color support across terminals:

https://gist.github.com/XVilka/8346728

@marvim marvim added the RFC label Mar 19, 2015

@rainerborene

This comment has been minimized.

Show comment
Hide comment
@rainerborene

rainerborene Mar 19, 2015

Contributor

This means the current TUI supports guifg and guibg colors If I enable that environment variable? Of course, using a terminal with true color support.

Contributor

rainerborene commented Mar 19, 2015

This means the current TUI supports guifg and guibg colors If I enable that environment variable? Of course, using a terminal with true color support.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 19, 2015

Is there any particular reason this is being done with an environment variable? I'm not a huge fan of adding yet another option, but it makes sense over an environment variable in this case IMO. The few env vars nvim does obey are for its initialization (e.g., VIMINIT), although I might be wrong on that.

ghost commented Mar 19, 2015

Is there any particular reason this is being done with an environment variable? I'm not a huge fan of adding yet another option, but it makes sense over an environment variable in this case IMO. The few env vars nvim does obey are for its initialization (e.g., VIMINIT), although I might be wrong on that.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Mar 19, 2015

Member

@Pyrohh Neither am I but we need some way to set the option per UI. E.g., ,one TUI may be running in a 16-color terminal, the other in 16-million, both connected to the same nvim.

Once we figure out a better approach, we can avoid many env vars currently floating around.

@rainerborene Yes.

Member

justinmk commented Mar 19, 2015

@Pyrohh Neither am I but we need some way to set the option per UI. E.g., ,one TUI may be running in a 16-color terminal, the other in 16-million, both connected to the same nvim.

Once we figure out a better approach, we can avoid many env vars currently floating around.

@rainerborene Yes.

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 19, 2015

@justinmk that's a good point, but I wonder if something like that could be automatically detected instead.

ghost commented Mar 19, 2015

@justinmk that's a good point, but I wonder if something like that could be automatically detected instead.

@XVilka

This comment has been minimized.

Show comment
Hide comment
@XVilka

XVilka Mar 20, 2015

@justinmk In fact I've started to adding true color support in the mintty, but not finished yet (lacking free time hardly) https://github.com/XVilka/mintty/commits/master (see last 3 commits).

XVilka commented Mar 20, 2015

@justinmk In fact I've started to adding true color support in the mintty, but not finished yet (lacking free time hardly) https://github.com/XVilka/mintty/commits/master (see last 3 commits).

@tarruda

This comment has been minimized.

Show comment
Hide comment
@tarruda

tarruda Mar 20, 2015

Member

@Pyrohh I don't like using environment variables either, but it is better than introduce coupling between the core and the UI. Later I will add support for UI-specific configuration through vimscript variables.

Member

tarruda commented Mar 20, 2015

@Pyrohh I don't like using environment variables either, but it is better than introduce coupling between the core and the UI. Later I will add support for UI-specific configuration through vimscript variables.

@justinmk

This comment has been minimized.

Show comment
Hide comment
@justinmk

justinmk Mar 20, 2015

Member

@XVilka very cool. Thanks for maintaining that gist also!

Member

justinmk commented Mar 20, 2015

@XVilka very cool. Thanks for maintaining that gist also!

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 20, 2015

@tarruda I see, that certainly makes sense.

ghost commented Mar 20, 2015

@tarruda I see, that certainly makes sense.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Mar 20, 2015

Contributor

@tarruda My 24-bit-xterm branch allows setting and removing true color support in the running Vim instance which is good should you add this to the vimrc and forget to add checks for terminal not supporting this. About VimL variables: how should this work given that there are no notifications for variable changes? Specifically for this case I would simply check variable on full redraw, but this is slightly worse then 24-bit-xterm variant where set guicolors causes full redraw.

Contributor

ZyX-I commented Mar 20, 2015

@tarruda My 24-bit-xterm branch allows setting and removing true color support in the running Vim instance which is good should you add this to the vimrc and forget to add checks for terminal not supporting this. About VimL variables: how should this work given that there are no notifications for variable changes? Specifically for this case I would simply check variable on full redraw, but this is slightly worse then 24-bit-xterm variant where set guicolors causes full redraw.

@ZyX-I

This comment has been minimized.

Show comment
Hide comment
@ZyX-I

ZyX-I Mar 20, 2015

Contributor

Also @tarruda has a valid concern which is not solved neither by VimL variables nor by options.

Except that if you have some identifier unique to each connected UI (e.g. position of UI in uis or UI* pointer address) you may make VimL variable a dictionary. You can’t do the same thing with options.

Thus I would suggest using

let g:ui_truecolor={
    'default': 1,
}
if !empty($STY.$TMUX)
    let g:ui_truecolor[0]=0
endif
" Do the same thing on attaching new UI. But I don’t know how: `UI` struct has no “get_ui_env_var” and there seems to be no UIAttached event.
Contributor

ZyX-I commented Mar 20, 2015

Also @tarruda has a valid concern which is not solved neither by VimL variables nor by options.

Except that if you have some identifier unique to each connected UI (e.g. position of UI in uis or UI* pointer address) you may make VimL variable a dictionary. You can’t do the same thing with options.

Thus I would suggest using

let g:ui_truecolor={
    'default': 1,
}
if !empty($STY.$TMUX)
    let g:ui_truecolor[0]=0
endif
" Do the same thing on attaching new UI. But I don’t know how: `UI` struct has no “get_ui_env_var” and there seems to be no UIAttached event.
tui: Add support for true color terminals
This is enabled by setting the `$NVIM_TUI_ENABLE_TRUE_COLOR` environment
variable, eg:

```
$ NVIM_TUI_ENABLE_TRUE_COLOR=1 nvim
```
@tarruda

This comment has been minimized.

Show comment
Hide comment
@tarruda

tarruda Mar 20, 2015

Member

@ZyX-I one way to enable a running instance is by setting $NVIM_TUI_ENABLE_TRUECOLOR and suspending/restoring nvim. In any case I think we do need a way to expose notifications about variable changes, which is not only useful for UI configuration but also for plugins in general

Member

tarruda commented Mar 20, 2015

@ZyX-I one way to enable a running instance is by setting $NVIM_TUI_ENABLE_TRUECOLOR and suspending/restoring nvim. In any case I think we do need a way to expose notifications about variable changes, which is not only useful for UI configuration but also for plugins in general

@tarruda tarruda merged commit 8dd415e into neovim:master Mar 20, 2015

0 of 2 checks passed

continuous-integration/travis-ci/pr The Travis CI build is in progress
Details
continuous-integration/travis-ci/push The Travis CI build is in progress
Details

@jszakmeister jszakmeister removed the RFC label Mar 20, 2015

@tarruda tarruda referenced this pull request in neovim/neovim.github.io Mar 20, 2015

Merged

Upcoming Newsletter #82

22 of 22 tasks complete
@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 20, 2015

@tarruda do you plan on documenting that variable? I'll send a PR for it if not.

ghost commented Mar 20, 2015

@tarruda do you plan on documenting that variable? I'll send a PR for it if not.

@tarruda

This comment has been minimized.

Show comment
Hide comment
@tarruda

tarruda Mar 20, 2015

Member

@tarruda do you plan on documenting that variable? I'll send a PR for it if not.

I'd appreciate if you did. While your'e at it, could you also document $NVIM_TUI_ENABLE_CURSOR_SHAPE?

Member

tarruda commented Mar 20, 2015

@tarruda do you plan on documenting that variable? I'll send a PR for it if not.

I'd appreciate if you did. While your'e at it, could you also document $NVIM_TUI_ENABLE_CURSOR_SHAPE?

@ghost

This comment has been minimized.

Show comment
Hide comment
@ghost

ghost Mar 20, 2015

Already on my to-do list :)

On March 20, 2015 4:09:51 PM EDT, Thiago de Arruda notifications@github.com wrote:

@tarruda do you plan on documenting that variable? I'll send a PR for
it if not.

I'd appreciate if you did. While your'e at it, could you also document
$NVIM_TUI_ENABLE_CURSOR_SHAPE?


Reply to this email directly or view it on GitHub:
#2198 (comment)

ghost commented Mar 20, 2015

Already on my to-do list :)

On March 20, 2015 4:09:51 PM EDT, Thiago de Arruda notifications@github.com wrote:

@tarruda do you plan on documenting that variable? I'll send a PR for
it if not.

I'd appreciate if you did. While your'e at it, could you also document
$NVIM_TUI_ENABLE_CURSOR_SHAPE?


Reply to this email directly or view it on GitHub:
#2198 (comment)

@woegjiub

This comment has been minimized.

Show comment
Hide comment
@woegjiub

woegjiub Mar 20, 2015

http://lists.schmorp.de/pipermail/rxvt-unicode/2013q3/001834.html

Rxvt-unicode refuses to support 'true colour', with the above explanation.
It has full support for 30-bit colour, just like xterm, and insists that there is a right way to do this, and that the 'true colour' standard is not it.

Is it worth attempting to use colour in that way, as opposed to this way?
For an example of use, w3m-img outputs full colour in terminals that support rxvt-unicode/xterm's way, which is apparently the earlier method.

http://lists.schmorp.de/pipermail/rxvt-unicode/2013q3/001834.html

Rxvt-unicode refuses to support 'true colour', with the above explanation.
It has full support for 30-bit colour, just like xterm, and insists that there is a right way to do this, and that the 'true colour' standard is not it.

Is it worth attempting to use colour in that way, as opposed to this way?
For an example of use, w3m-img outputs full colour in terminals that support rxvt-unicode/xterm's way, which is apparently the earlier method.

@tarruda

This comment has been minimized.

Show comment
Hide comment
@tarruda

tarruda Mar 20, 2015

Member

@woegjiub more than 24 bit colors is useless for Neovim since you cant specify the alpha component in color schemes.

I've seen that post and their argument is weak. It can be simplified as "Since terminfo exposes codes of changing the color palette, programs should use that(because its "portable") even though its much hackier and messier than simply specifying the RGB colors directly."

Terminfo is not reliable and does not support some new terminal features such as bracketed paste, thats why many terminals follow "xterm compliance" instead of being limited to what is available on terminfo.

Member

tarruda commented Mar 20, 2015

@woegjiub more than 24 bit colors is useless for Neovim since you cant specify the alpha component in color schemes.

I've seen that post and their argument is weak. It can be simplified as "Since terminfo exposes codes of changing the color palette, programs should use that(because its "portable") even though its much hackier and messier than simply specifying the RGB colors directly."

Terminfo is not reliable and does not support some new terminal features such as bracketed paste, thats why many terminals follow "xterm compliance" instead of being limited to what is available on terminfo.

@lithammer lithammer referenced this pull request in w0ng/vim-hybrid Mar 22, 2015

Closed

Doesn't load properly when using true color in Neovim #27

@pacuna

This comment has been minimized.

Show comment
Hide comment
@pacuna

pacuna Mar 23, 2015

I'm trying this feature with the solarized scheme and works great, but when I open nvim, the colorscheme isn't being loaded. I have to set the colorscheme again, even if it's declared in my .nvimrc.
Is this an issue related to the colorscheme?

thanks!

pacuna commented Mar 23, 2015

I'm trying this feature with the solarized scheme and works great, but when I open nvim, the colorscheme isn't being loaded. I have to set the colorscheme again, even if it's declared in my .nvimrc.
Is this an issue related to the colorscheme?

thanks!

@tarruda

This comment has been minimized.

Show comment
Hide comment
@tarruda

tarruda Mar 23, 2015

Member

@pacuna I think this is related to how colorschemes are initialized using has('gui_running')(which is only set after the UI loads). What happens if you load the colorscheme using the VimEnter autocmd?

Member

tarruda commented Mar 23, 2015

@pacuna I think this is related to how colorschemes are initialized using has('gui_running')(which is only set after the UI loads). What happens if you load the colorscheme using the VimEnter autocmd?

@pacuna

This comment has been minimized.

Show comment
Hide comment
@pacuna

pacuna Mar 23, 2015

@tarruda yeah that did the trick :D, thanks!!

pacuna commented Mar 23, 2015

@tarruda yeah that did the trick :D, thanks!!

@ghost ghost referenced this pull request Apr 2, 2015

Closed

Enabling true color from .nvimrc #2334

@meunierd meunierd referenced this pull request in NLKNguyen/papercolor-theme Jun 1, 2015

Closed

Better Terminal Detection #4

@tonatiuh tonatiuh referenced this pull request in dracula/dracula-theme Oct 17, 2015

Closed

Vim colors not as displayed in the preview #80

@avrono avrono referenced this pull request in joshdick/onedark.vim Mar 21, 2018

Closed

Errors on vim 8 install #118

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment