Add support for 24-bit color

[agriffis]

Lots of terms and related programs are gaining support for 24-bit color escapes, see https://gist.github.com/XVilka/8346728

I'd love to see support for this in mosh. Creating this issue to gather information on what's needed in mosh, and to coordinate any effort around it.

[keithw]

No fundamental objection to supporting this, but what terminfo entry are these in?

Right now the mosh-client gets the number of client colors with tigetnum( "colors" ) (see https://github.com/keithw/mosh/blob/master/src/frontend/mosh-client.cc#L87), and then based on that answer, the mosh-server ends up advertising either TERM=xterm or TERM=xterm-256color to the host applications.

What TERM can mosh-server advertise to indicate that it supports these truecolor escape sequences, and how can mosh-client determine if the client supports them?

[cgull]

This is all quite doable, but there are issues to work through:

This adds a fourth set of rendering attributes to character cells (VT100, 16-color, 256-color, true-color). Since Mosh is a virtual terminal that uses an unknown real terminal for its final rendering, I think it has to maintain and pass through all four sets of attributes. 16-color attributes can't be converted to RGB because different terminals choose different colors, often user configurable. 256-color attributes could be converted to RGB, but I think performance and compatibility issues will weigh against that.

I'm a bit concerned about performance. Adding support for this will add 6+ bytes to each Terminal::Framebuffer::Cell, but more importantly, the escape sequences are verbose (14 characters minimum to set just foreground or background, 21 to set both). We will want to pass as few of these as possible. 256-color attributes are a third shorter than this and should be passed as such.

Implementation for this will touch the same code as my upcoming performance changes.

What do we do with a terminal emulator that doesn't support true-color mode? Passing this stuff through to a truly ignorant terminal will result in RGBake (you get the right characters, tossed in a fruit salad of colors/attributes). We can either ignore the problem, or we can do truecolor detection similar to Mosh's existing 16/256-color detection.

If we don't implement this soon, we should at least implement detection of these sequences so that we properly ignore them.

https://groups.google.com/forum/#!msg/iterm2-issues/NXLGvwuzjrc/35gVs4pfjLYJ has a fair bit of relevant commentary.

[cgull]

I spent a while gnawing on this last night. It's complicated, and I found we're not currently fully/correctly supporting 256-color attributes, either.

Turns out that X3.64 and friends are extremely vague in this area and so XTerm initially misimplemented them for 256 color attributes (and the full-color attributes extend on that code and work the same way). So XTerm supports 3 ways to do 256-color attributes:

• everything's separated by semicolons \e[38;5;1m. This is the initial, popular, yet "wrong" implementation.
• the second parameter has colon-delimited subparameters \e[38;5:1m-- this is what the standards seem to recommend, but still a bad design.
• the first parameter has subparameters \e[38:5:1m

Full-color modes work the same way, with two extra (sub)parameters.

And of course, we should properly process or ignore these. All of these schemes suck in one way or another, and handling the 6 possible types of sequences sucks more.

Currently, we only support semicolons. I suspect that in practice, the colon-delimited modes are rarely if ever used for 256-color attributes, because of XTerm's initial misimplementation (which went unrecognized for a decade, I think) and other terminal emulators copying it initially. We don't seem to have had trouble from this. I'd hope to think the same is true of full-color attributes but I don't know.

More useful commentary:
https://bugs.kde.org/show_bug.cgi?id=107487
XTerm source (warning, not an authoritative repo-- there is none for XTerm; it's tarballs all the way down)

[pickfire]

+1 for mosh supporting true colors. I hope mosh can be in the hall of fame in https://gist.github.com/XVilka/8346728.

[colemickens]

+1. tmux master now supports 24bit color: tmux/tmux#34 (comment) along with all libvte based terminals.

I've stopped using mosh since adopting true color in neovim and I miss the snappiness.

[abrooks]

+1. mosh has great terminal emulation it would be delightful to have 24-bit color be part of that.

[placeybordeaux]

Looks like this didn't land in the performance update? It seems to me like just handling the semicolon case will put mosh on an equal playing field as many other terminal emulators, but handling all three cases would put it above and beyond.

Getting 24bit color support to land in mosh would be excellent, I am another user that am feeling the pain after neovim adopted true color, I consistently need to switch colorschemes depending on if I am using ssh or mosh.

[idvorkin]

I've been playing with Mosh and it looks amazing - any idea when true color will be supported?

[jamiedumont]

I'd like to add my 👍 to finding a way of integrating 24bit colour support. It's not a deal breaker, but when using something as awesome as Mosh, it's nice to have all the toys too! 😄

[vvug]

Any news about this? The lack of truecolor support doesn't only mean that the color is approximated to the nearest color in a 256 color palette, I'm just getting seemingly random, very bad colors...

Thank you!

[blark]

This would be very nice.

Edit

Come on, even Windows has truecolor support now... :) https://blogs.msdn.microsoft.com/commandline/2016/09/22/24-bit-color-in-the-windows-console/

[kevinkjt2000]

Can the issues that need to be worked through be created and referenced here? I'm not an expert at terminal emulators, but I would gladly bite into smaller issues to help support true color in mosh :)