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 :)

[msva]

ping? any news about this feature?
// maybe bounty-source it, if no one has enough time/interest to do that?

[andersk]

This was added in #939.

[eminence]

To anyone who's been waiting for this feature: it would be really awesome if you could build the latest master version of mosh and help test it out!

[msva]

IIRC, I've already reported on IRC that it works like a charm!

// well, at least, I didn;t still catched any color-related bug

[patricklewis]

Compiled from master and Truecolor support's looking great so far in Vim 8 and tmux over mosh.

[kalashnikov]

Build at RHEL6, connect from iTerm2 and use with tmux. Neovim. Everything looks great!

…

IIRC, I've already reported on IRC that it works like a charm! // well, at least, I didn;t still catched any color-related bug — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#649 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAv6Uvz6xCmzD4o8U18CuVc6wsafK_iks5szy0ngaJpZM4FXYVV> .

[kevinkjt2000]

It worked for me! Even when I started a tmux session on the remote. Much kudos to all who made it happen!

[lithammer]

@carlosvigil https://github.com/mobile-shell/mosh/wiki/Build-Instructions

[carlosvigil]

Ah sorry, was on mobile. Thank you. Blink shell doesn’t support yet but I’ve mentioned that it’s possible now. Thanks!

[ghost]

I can't get true colours to work at all on High Sierra:

$ brew info mosh
mosh: stable 1.3.2 (bottled), HEAD
Remote terminal application
https://mosh.org
/usr/local/Cellar/mosh/HEAD-6fb4d0d_1 (14 files, 953.9KB) *
  Built from source on 2017-11-10 at 09:42:15 with: --with-test
From: https://github.com/Homebrew/homebrew-core/blob/master/Formula/mosh.rb
==> Dependencies
Build: pkg-config ✔
Required: protobuf ✔
==> Options
--with-test
        Run build-time tests
--HEAD
        Install HEAD version
==> Caveats
Bash completion has been installed to:
  /usr/local/etc/bash_completion.d

$ mosh --version
mosh 1.3.2 [build mosh-1.3.2-55-g6fb4d0d-dirty]
Copyright 2012 Keith Winstein <mosh-devel@mit.edu>
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>.
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.

The following images are connections vis ssh and mosh to a tmux session:

Do I have to change TERM to something specific?

Thanks :-)

[ghost]

doh, of course, I only compiled the client end - how embarrassing :-(

Now it's working :-)

Thanks for the great work!

[makew0rld]

What version is needed? It doesn't work for me with version 1.3.2 on both ends.

[0xallie]

You need to build it from git yourself. There have been no releases for years, so none of them include true color support.

[kevinkjt2000]

@makeworld-the-better-one I have been installing with brew install --HEAD mosh to pick up the unreleased feature from git. Hope that helps (since brew is relatively simple to install).

[agriffis]

On Fedora you can use https://copr.fedorainfracloud.org/coprs/agriffis/mosh-nightly/

[akorchemniy]

Can we have a new release. I've been waiting for years :)