[RFC] tui: Add support for true color terminals

[tarruda]

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

$ NVIM_TUI_ENABLE_TRUE_COLOR=1 nvim

Close #59

[justinmk]

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

[rainerborene]

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]

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]

@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]

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

[XVilka]

@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]

@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]

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

[ghost]

@tarruda I see, that certainly makes sense.

[ZyX-I]

@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]

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.

[tarruda]

@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

[ghost]

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

[tarruda]

@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]

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)

[jadedarko]

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]

@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.

[pacuna]

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]

@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]

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