add support for 24-bit RGB color escape sequences

[sunaku]

This patch adds support for 24-bit RGB color escape sequences, requested
in issue #34, by adjusting Koichi Shiraishi's patch 2, which derives
from Christian Hopps's patch 3, which in turn derives from Arnis
Lapsa's patch 4, according to feedback given by Nicholas Marriott 1.

[nicm]

This is something at least, although you didn't read my previous
comments :-). Here are some comments:

• I do not want to support : as a separator for all escape sequences, or
  in fact for any, including the RGB sequence. So that part of the diff
  can be removed.

• This is adding too many bytes to grid_cell. You do not need to use the
  entire colour_rgb struct or to call colour_find_rgb, you should reuse
  the existing fg and bg either by using them for one component manually
  or by doing something like:

  struct grid_cell {
  u_char attr;
  u_char flags;
  union {
  u_char fg;
  struct rgb_fg {
  u_char r;
  u_char g;
  u_char b;
  };
  };
  union {
  u_char bg;
  struct rgb_fg {
  u_char r;
  u_char g;
  u_char b;
  };
  };
  ...

• Use memcpy not struct assignment please (so memcpy instead of
  gc->bg_rgb = rgb - although this will go away when you fix the last
  point).

• Don't send diffs with FIXME comments please... you will need make tmux
  look for a Tc terminfo entry (that can initially be added with
  terminal-overrides). Please don't add a command line flag like -2.

• Likewise what is the code commented out in input_csi_dispatch_sgr_rgb
  for? You probably do need to reset the 256 colour flags there.

• You forgot about grid_string_cells.

• Ultimately I think this will need to replace 256 colours but I am
  happy to see that done after this diff is good.

On Thu, Sep 17, 2015 at 01:41:31PM -0700, Suraj N. Kurapati wrote:

This patch adds support for 24-bit RGB color escape sequences, requested
in issue [1]#34, by adjusting Koichi Shiraishi's patch [2]2, which derives
from Christian Hopps's patch [3]3, which in turn derives from Arnis
Lapsa's patch [4]4, according to feedback given by Nicholas Marriott [5]1.

---

You can view, comment on, or merge this pull request online at:

 [6]https://github.com/tmux/tmux/pull/112

Commit Summary

 * add support for 24-bit RGB color escape sequences

File Changes

 * M [7]colour.c (6)
 * M [8]input.c (29)
 * M [9]tmux.h (12)
 * M [10]tty.c (76)

Patch Links:

 * [11]https://github.com/tmux/tmux/pull/112.patch
 * [12]https://github.com/tmux/tmux/pull/112.diff

--
Reply to this email directly or [13]view it on GitHub.

Reverse link: [14]unknown

References

Visible links

1. Add TrueColor Support
   Add TrueColor Support #34
2. https://gist.github.com/zchee/9f6f2ca17acf49e04088
3. https://gist.github.com/choppsv1/dd00858d4f7f356ce2cf
4. https://gist.github.com/ArnisL/6156593
5. Add TrueColor Support #34 (comment)
6. add support for 24-bit RGB color escape sequences #112
7. https://github.com/tmux/tmux/pull/112/files#diff-0
8. https://github.com/tmux/tmux/pull/112/files#diff-1
9. https://github.com/tmux/tmux/pull/112/files#diff-2
   1. https://github.com/tmux/tmux/pull/112/files#diff-3
   2. https://github.com/tmux/tmux/pull/112.patch
   3. https://github.com/tmux/tmux/pull/112.diff
   4. add support for 24-bit RGB color escape sequences #112
   5. add support for 24-bit RGB color escape sequences #112

[dequis]

Thanks @sunaku for picking this up! Also thanks @nicm for the helpful review comments!

you will need make tmux look for a Tc terminfo entry (that can initially be added with terminal-overrides).

Interesting idea, would that mean bypassing the problem of the terminfo maintainer? Should other applications check for that Tc entry too?

[nicm]

We will need some way to detect it, and there is no point in proposing a flag to Thomas Dickey that we might need, or might not, and we aren't even using. Once we have code and know that adding a flag is the best solution for tmux, we can see what he thinks - perhaps he will suggest something else, or perhaps we will have to keep it as an extension, or do something else. There is no problem yet.

[sunaku]

On Thu, 17 Sep 2015 14:20:25 -0700, Nicholas Marriott wrote:

This is something at least, although you didn't read my previous
comments :-).

Sorry about that! This patch was indeed a work in progress; I was
mainly focused on reducing unnecessary elements from the prior one.

Here are some comments:

• I do not want to support : as a separator for all escape sequences, or
  in fact for any, including the RGB sequence. So that part of the diff
  can be removed.

Agreed, will do.

• This is adding too many bytes to grid_cell. You do not need to use the
  entire colour_rgb struct or to call colour_find_rgb, you should reuse
  the existing fg and bg either by using them for one component manually
  or by doing something like:

  struct grid_cell {
  u_char attr;
  u_char flags;
  union {
  u_char fg;
  struct rgb_fg {
  u_char r;
  u_char g;
  u_char b;
  };
  };
  union {
  u_char bg;
  struct rgb_fg {
  u_char r;
  u_char g;
  u_char b;
  };
  };
  ...

• Use memcpy not struct assignment please (so memcpy instead of
  gc->bg_rgb = rgb - although this will go away when you fix the last
  point).

How about storing colors in 32-bit unsigned integers as 0xRRGGBBII?

The upper bytes will hold the red, green, and blue channel values.

The lowest byte will hold either (1) the 256-color index or (2) the
native 16-color, 8-color, or monochrome color value. To distinguish
these two use-cases, we'll decipher the upper byte values as follows:

• All zero upper bytes (0x000000II) indicate II is a native color.
• All 0xFF upper bytes (0xFFFFFFII) indicate II is a 256-color index.
• Non-zero upper bytes (0x------II) indicate II is nearest 256-color.

It seems that this scheme allows us to forgo storing the grid_cell
flags as well because colors now provide both RGB and indexed values,
so we can decide (at emission time) which to use based on terminal
capabilities (as is currently done with the aid of grid_cell flags).

In addition, this scheme will eliminate struct copying and simplify
RGB color equality checking (which is done channel-by-channel now).

• Don't send diffs with FIXME comments please... you will need make tmux
  look for a Tc terminfo entry (that can initially be added with
  terminal-overrides). Please don't add a command line flag like -2.

Thanks, I was searching the web for the name of an existing 24-bit
terminfo entry but only found that no such thing officially exists!

• Likewise what is the code commented out in input_csi_dispatch_sgr_rgb
  for? You probably do need to reset the 256 colour flags there.

Since we first try emitting RGB and fall back to 256-color anyway,
do RGB and 256-color flags really need to be mutually exclusive?

• You forgot about grid_string_cells.

Thanks, I'll look into it.

• Ultimately I think this will need to replace 256 colours but I am
  happy to see that done after this diff is good.

Thanks for your feedback and patience. I will push additional
commits to this pull request and, once the net result is
satisfactory, I'll squash them and force-push a single final patch.

[nicm]

I don't think it will be better to use 32 bits for the colour. It is a
nice idea, but the main problem with RGB colour is that it adds 4 bytes
to struct grid_cell (so 30% more memory use) for something very few
people will use, and most of those who do will use it for the minority
of cells. Adding 6 bytes instead is less helpful. If you can put the
flags in there too it'd be fine, but then you will have bit shifting and
masks everywhere so it'll be just as bad.

This is a real concern - for example I have 6 MB of history here with
relatively few windows. I am not particularly interested in Internet
hipsters running tmux on the VAX or some other truly ancient, dead
thing, but there are newer (like SPARC) and even modern platforms (like
ARM) that often have limited RAM too.

I did plan to have a separate array of long cells where if the character
was more than one byte, the cell would be a offset into the array
instead, that way cells could mostly be four or six bytes with a few
larger ones being an offset instead of the cell data. That's why there
are accessors for the character data in grid-cell.c. But I didn't get
round to doing it. If we had that, we could use it for cells with RBG
colours too, although there would need to be accessors for getting
colours and attributes too (at the moment there are only accessors for
character data).

As far as 256 and RGB being mutually exclusive - you should never have a
cell with both flags set, there can only be one colour at a time.

On Sat, Sep 19, 2015 at 03:17:45PM -0700, Suraj N. Kurapati wrote:

On Thu, 17 Sep 2015 14:20:25 -0700, Nicholas Marriott wrote:

This is something at least, although you didn't read my previous
comments :-).

Sorry about that! This patch was indeed a work in progress; I was
mainly focused on reducing unnecessary elements from the prior one.

Here are some comments:

• I do not want to support : as a separator for all escape sequences, or
  in fact for any, including the RGB sequence. So that part of the diff
  can be removed.

Agreed, will do.

• This is adding too many bytes to grid_cell. You do not need to use the
  entire colour_rgb struct or to call colour_find_rgb, you should reuse
  the existing fg and bg either by using them for one component manually
  or by doing something like:

struct grid_cell {
u_char attr;
u_char flags;
union {
u_char fg;
struct rgb_fg {
u_char r;
u_char g;
u_char b;
};
};
union {
u_char bg;
struct rgb_fg {
u_char r;
u_char g;
u_char b;
};
};
...

• Use memcpy not struct assignment please (so memcpy instead of
  gc->bg_rgb = rgb - although this will go away when you fix the last
  point).

How about storing colors in 32-bit unsigned integers as 0xRRGGBBII?

The upper bytes will hold the red, green, and blue channel values.

The lowest byte will hold either (1) the 256-color index or (2) the
native 16-color, 8-color, or monochrome color value. To distinguish
these two use-cases, we'll decipher the upper byte values as follows:

• All zero upper bytes (0x000000II) indicate II is a native color.

• All 0xFF upper bytes (0xFFFFFFII) indicate II is a 256-color index.

• Non-zero upper bytes (0x------II) indicate II is nearest 256-color.

  It seems that this scheme allows us to forgo storing the grid_cell
  flags as well because colors now provide both RGB and indexed values,
  so we can decide (at emission time) which to use based on terminal
  capabilities (as is currently done with the aid of grid_cell flags).

  In addition, this scheme will eliminate struct copying and simplify
  RGB color equality checking (which is done channel-by-channel now).

  • Don't send diffs with FIXME comments please... you will need make tmux
    look for a Tc terminfo entry (that can initially be added with
    terminal-overrides). Please don't add a command line flag like -2.

  Thanks, I was searching the web for the name of an existing 24-bit
  terminfo entry but only found that no such thing officially exists!

  • Likewise what is the code commented out in input_csi_dispatch_sgr_rgb
    for? You probably do need to reset the 256 colour flags there.

  Since we first try emitting RGB and fall back to 256-color anyway,
  do RGB and 256-color flags really need to be mutually exclusive?

  • You forgot about grid_string_cells.

  Thanks, I'll look into it.

  • Ultimately I think this will need to replace 256 colours but I am
    happy to see that done after this diff is good.

  Thanks for your feedback and patience. I will push additional
  commits to this pull request and, once the net result is
  satisfactory, I'll squash them and force-push a single final patch.

  Reply to this email directly or [1]view it on GitHub.

  Reverse link: [2]unknown

References

Visible links

1. add support for 24-bit RGB color escape sequences #112 (comment)
2. add support for 24-bit RGB color escape sequences #112 (comment)

[zchee]

@sunaku Thanks for rework my patch.
@nicm Thanks the helpful review comments.

I'm not good at C language, I will watch for a while this PR.

[jfelchner]

@sunaku and you so much for taking the time to help make this happen. There are quite a few people who are waiting with baited breath for this to land. 😀

@nicm your comments are awesome. Thanks for taking such time to help point @sunaku to something that you'll be willing to merge. 🚢

[sunaku]

On Sun, 20 Sep 2015 01:36:27 -0700, Nicholas Marriott wrote:

I don't think it will be better to use 32 bits for the colour. It
is a nice idea, but the main problem with RGB colour is that it
adds 4 bytes to struct grid_cell (so 30% more memory use) for
something very few people will use, and most of those who do will
use it for the minority of cells. Adding 6 bytes instead is less
helpful. If you can put the flags in there too it'd be fine, but
then you will have bit shifting and masks everywhere so it'll be
just as bad.

This is a real concern - for example I have 6 MB of history here
with relatively few windows. I am not particularly interested in
Internet hipsters running tmux on the VAX or some other truly
ancient, dead thing, but there are newer (like SPARC) and even
modern platforms (like ARM) that often have limited RAM too.

That makes sense; agreed.

I did plan to have a separate array of long cells where if the
character was more than one byte, the cell would be a offset into
the array instead, that way cells could mostly be four or six
bytes with a few larger ones being an offset instead of the cell
data. That's why there are accessors for the character data in
grid-cell.c. But I didn't get round to doing it. If we had that,
we could use it for cells with RBG colours too, although there
would need to be accessors for getting colours and attributes too
(at the moment there are only accessors for character data).

Would you like me to pursue this route? Or perhaps you might
refactor toward it later, after this patch has been reworked?

As far as 256 and RGB being mutually exclusive - you should never
have a cell with both flags set, there can only be one colour at a
time.

In that case, what should happen when a 24-bit color is specified
for a grid_cell, but the current TTY lacks 24-bit color capability?

Do we dynamically degrade the 24-bit color down to the next highest
level of color fidelity (256-color, 88-color, 16-color, 8-color,
2-color, 1-color) supported by the current TTY at emission time?

[nicm]

On Tue, Sep 22, 2015 at 10:20:33PM -0700, Suraj N. Kurapati wrote:

I did plan to have a separate array of long cells where if the
character was more than one byte, the cell would be a offset into
the array instead, that way cells could mostly be four or six
bytes with a few larger ones being an offset instead of the cell
data. That's why there are accessors for the character data in
grid-cell.c. But I didn't get round to doing it. If we had that,
we could use it for cells with RBG colours too, although there
would need to be accessors for getting colours and attributes too
(at the moment there are only accessors for character data).

Would you like me to pursue this route? Or perhaps you might
refactor toward it later, after this patch has been reworked?

I suggest doing it later but for now keep grid_cell as small as
practical.

As far as 256 and RGB being mutually exclusive - you should never
have a cell with both flags set, there can only be one colour at a
time.

In that case, what should happen when a 24-bit color is specified
for a grid_cell, but the current TTY lacks 24-bit color capability?

Do we dynamically degrade the 24-bit color down to the next highest
level of color fidelity (256-color, 88-color, 16-color, 8-color,
2-color, 1-color) supported by the current TTY at emission time?

Yes, except only 256 and 16/8 colours. You probably just need to add
something using colour_find_rgb in tty_check_fg and tty_check_bg.

[sunaku]

On Wed, 23 Sep 2015 00:44:58 -0700, Nicholas Marriott wrote:

On Tue, Sep 22, 2015 at 10:20:33PM -0700, Suraj N. Kurapati wrote:

Do we dynamically degrade the 24-bit color down to the next highest
level of color fidelity (256-color, 88-color, 16-color, 8-color,
2-color, 1-color) supported by the current TTY at emission time?

Yes, except only 256 and 16/8 colours. You probably just need to add
something using colour_find_rgb in tty_check_fg and tty_check_bg.

Hmm, in my review of tty.c, that doesn't exactly seem to be the case:
tty_colours() and its children tty_colours_fg() and tty_colours_bg()
modify the colour values in gc, the grid_cell, itself rather than
tc, the current terminal grid_cell, during graceful degradation.

As a result, we may lose colour information when, say, specifying a
24-bit colour whilst connected to a non-true-colour terminal and
then reattaching tmux to a true-colour terminal. The original
24-bit colour would have already been degraded down to a 256-colour
or 16-colour representation before the latter terminal sees it.

Is this correct?

P.S. I have force-pushed an updated patch implementing Tc terminfo
lookup and tty_check_[fb]g() consideration, but colour_fromstring()
is still pending. Please have a (cursory) look to keep me on track
with your vision of the final patch. Thanks for your consideration.

[nicm]

No: tty_check_fg, tty_check_bg and tty_colours all operate on a
grid_cell on the stack. Look at tty_attributes. Please link me to an
updated patch and I will take a look.

On Sat, Sep 26, 2015 at 03:29:39PM -0700, Suraj N. Kurapati wrote:

On Wed, 23 Sep 2015 00:44:58 -0700, Nicholas Marriott wrote:

On Tue, Sep 22, 2015 at 10:20:33PM -0700, Suraj N. Kurapati wrote:

Do we dynamically degrade the 24-bit color down to the next highest
level of color fidelity (256-color, 88-color, 16-color, 8-color,
2-color, 1-color) supported by the current TTY at emission time?

Yes, except only 256 and 16/8 colours. You probably just need to add
something using colour_find_rgb in tty_check_fg and tty_check_bg.

Hmm, in my review of tty.c, that doesn't exactly seem to be the case:
tty_colours() and its children tty_colours_fg() and tty_colours_bg()
modify the colour values in gc, the grid_cell, itself rather than
tc, the current terminal grid_cell, during graceful degradation.

As a result, we may lose colour information when, say, specifying a
24-bit colour whilst connected to a non-true-colour terminal and
then reattaching tmux to a true-colour terminal. The original
24-bit colour would have already been degraded down to a 256-colour
or 16-colour representation before the latter terminal sees it.

Is this correct?

P.S. I have force-pushed an updated patch implementing Tc terminfo
lookup and tty_check_[fb]g() consideration, but colour_fromstring()
is still pending. Please have a (cursory) look to keep me on track
with your vision of the final patch. Thanks for your consideration.

--
Reply to this email directly or [1]view it on GitHub.

Reverse link: [2]unknown

References

Visible links

1. add support for 24-bit RGB color escape sequences #112 (comment)
2. add support for 24-bit RGB color escape sequences #112 (comment)

[jfelchner]

@nicm on github when you force push a PR the existing PR is updated with the new overwritten commits.

[sunaku]

On Sat, 26 Sep 2015 16:25:12 -0700, Nicholas Marriott wrote:

tty_check_fg, tty_check_bg and tty_colours all operate on a
grid_cell on the stack. Look at tty_attributes.

Thanks for the hint! Will do.

Please link me to an updated patch and I will take a look.

Sure, here is the colourful web version:
https://github.com/tmux/tmux/pull/112/files

Or if you like, the traditional version:
https://github.com/tmux/tmux/pull/112.patch

These links always reflect the current state of the patch / PR.

[nicm]

Hi

Thanks. Some comments:

You don't need the changes to the input_transition structs.

I think where you have:

      gc->flags &= ~GRID_FLAG_BG256;
      gc->flags &= ~GRID_FLAG_BGRGB;

It would be better just as gc->flags &= ~(GRID_FLAG_BG256|GRID_FLAG_BGRGB).

I don't like defining the struct inside the union, define it outside
then just use it inside. Also grid_cell_colour_rgb is too long, maybe
just grid_cell_rgb?

I think the big check at the start of tty_colours could be broken up to
be more readable, maybe using a temporary flag, something like (not
tested):

changed = 0;
if (flags ^ tc->flags) & (GRID_FLAG_FG256|GRID_FLAG_BG256)) != 0)
changed = 1;
if (flags ^ tc->flags) & (GRID_FLAG_FGRGB|GRID_FLAG_BGRGB)) != 0)
changed = 1;
if (!changed && (flags & GRID_FLAG_FG256)) {
if (gc->fg != tc->fg)
changed = 1;
} else if (!changed && (flags & GRID_FLAG_FGRGB)) {
if (gc->fg_rgb.r != tc->fg_rgb.r)
changed = 1;
... and so on ...
}
... same for bg ...
if (!changed)
return;

Perhaps this bit could set multiple flags since basically the same
checks are later done under "/* Set the foreground colour. */". Not sure
if that would make it too hard to read though.

Otherwise looks good so far.

[bergman]

I tried this on 2.1 and current master and it did not work. Colors in 256 color mode worked fine but 24bit/truecolor was black/white. There was also a gray color coming in sometimes, like when splitting, one of the splits would get a gray background color.

[bsod90]

Just tried building this branch on ubuntu. Here's what I get: http://d.pr/i/1fI1N right after tmux start (gray scree, already in copy mode).
tmux 2.0 with this patch https://gist.github.com/choppsv1/dd00858d4f7f356ce2cf works well. tmux 2.1 is incompatible with that patch.

[jfelchner]

@sunaku how're we doin over there? 😋

[sunaku]

😰 Free time is scarce, I'll try this week. ⏳

[jfelchner]

@sunaku no rush man. We've waited this long. 😀 I know how it is. I'll just ping you every once in a while so you don't forget. 😉

[sunaku]

@bergman @bsod90 This patch "did not work" for you because it has evolved beyond the previous ones (upon which it builds) to properly require your terminal to advertise a Tc (24-bit / true color) capability before it attempts to emit those 24-bit RGB escape sequences. 😅 In contrast, its predecessors blindly assume that your terminal (regardless of what it actually is) supports 24-bit colors and blast away! 🔫

For the time being, you'll need to fake the Tc capability (because no such thing officially exists yet 🎱) by configuring tmux's terminal-overrides option as follows:

tmux set-option -ga terminal-overrides ',xterm*:Tc'

Don't give up on progress! 🚀

[sunaku]

@nicm I've been working through your suggestions but I've hit a roadblock regarding how the Tc capability is meant to be specified. In particular, this little command seems like it ought to work:

tmux set-option -ga terminal-overrides ',xterm*:Tc'

but the tty_term_override() function isn't being triggered by it (according to -vvv logs and my added log_debug() lines therein) 😱. As a result, tmux still thinks that Tc is not supported. 😢

Any ideas? 😰 Thanks for your consideration.

[nicm]

After tmux starts does "show -s terminal-overrides" have your additions?

But "tmux info" shows Tc as missing?

It looks fine to me, you should try adding some debugging to
tty_term_override.

You should use tty_term_flag to check Tc, not tty_term_has. And the
tty_term_codes array should be sorted.

On Thu, Oct 22, 2015 at 08:44:19PM -0700, Suraj N. Kurapati wrote:

[1]@nicm I've been working through your suggestions but I've hit a
roadblock regarding how the Tc capability is meant to be specified. In
particular, this little command seems like it ought to work:

tmux set-option -ga terminal-overrides ',xterm*:Tc'

but the tty_term_override() function isn't being triggered by it
(according to -vvv logs and my added log_debug() lines therein)
[2]:scream:. As a result, tmux still thinks that Tc is not supported.
[3]:cry:

Any ideas? [4]:cold_sweat: Thanks for your consideration.

--
Reply to this email directly or [5]view it on GitHub.

Reverse link: [6]unknown

References

Visible links

1. https://github.com/nicm
2. add support for 24-bit RGB color escape sequences #112 (comment)
3. add support for 24-bit RGB color escape sequences #112 (comment)

[bergman]

Confirmed working after adding set-option -ga terminal-overrides ",xterm*:Tc" to ~/.tmux.conf

I do have some weird stuff happening, like below, where colors are messed up after the first colored output and even more messed up after first background colored output:

Compare 2.0 with choppsv1's patch

For anyone wanting to try it out with homebrew:

diff --git a/Library/Formula/tmux.rb b/Library/Formula/tmux.rb
index 44d0dd1..a2e3232 100644
--- a/Library/Formula/tmux.rb
+++ b/Library/Formula/tmux.rb
@@ -22,6 +22,12 @@ class Tmux < Formula
   depends_on "pkg-config" => :build
   depends_on "libevent"

+  option "with-truecolor", "Build with truecolor patch enabled"
+  patch do
+    url "https://github.com/tmux/tmux/pull/112.diff"
+    sha1 "eac7a6d755df770257267f131bffffa1dfd94f29"
+  end if build.with? "truecolor"
+
   def install
     system "sh", "autogen.sh" if build.head?

[sunaku]

@nicm Thanks, this is truly weird. 😨 The overrides are taking effect only after I restart tmux:

$ ./tmux -vvv -L test -f /dev/null
# (now I'm inside the tmux session)

$ ./tmux show -s terminal-overrides
terminal-overrides "xterm*:XT:Ms=\E]52;%p1%s;%p2%s\007:Cs=\E]12;%p1%s\007:Cr=\E]112\007:Ss=\E[%p1%d q:Se=\E[2 q,screen*:XT"

$ ./tmux info | grep Tc
 201: Tc: [missing]

$ ./tmux set-option -ga terminal-overrides ',xterm*:Tc'

$ ./tmux info | grep Tc
 201: Tc: [missing]

$ exit

Now I restart tmux and this time it somehow remembers 👻 the overrides I previously set:

$ ./tmux -vvv -L test -f /dev/null
# (now I'm inside the tmux session)

$ ./tmux show -s terminal-overrides
terminal-overrides "xterm*:XT:Ms=\E]52;%p1%s;%p2%s\007:Cs=\E]12;%p1%s\007:Cr=\E]112\007:Ss=\E[%p1%d q:Se=\E[2 q,screen*:XT,xterm*:Tc"

$ ./tmux info | grep Tc
 201: Tc: (flag) true

Is this expected? 😕

[rhysd]

I tried this PR in my local machine (MacBook Pro Retina 2015, iTerm2) and it rendered Neovim with 24bit colors perfectly! Thank you so much 😄

[nicm]

Applied now.

[zchee]

@nicm 🎉
Thanks !!

[dasJ]

Thank you so much! 👍

On Fri, Jan 29, 2016, 13:08 Koichi Shiraishi notifications@github.com
wrote:

@nicm https://github.com/nicm [image: 🎉]
Thanks !!

—
Reply to this email directly or view it on GitHub
#112 (comment).

[rhysd]

🎉

[martin-svk]

Does it mean this was merged and tmux will have true colors support in next realease?

[XVilka]

@martin-svk yes, see commit 427b820

[martin-svk]

@XVilka thanks for clarification.

That's awesome, finally I will be able to use all those fancy color schemes 👍 🎉

[jfelchner]

Thank you all! Especially @sunaku. I've been waiting for this for a long time. What a fantastic job. 😀

[sunaku]

Thanks everyone ☺️ but we couldn't have done this without @nicm's tremendous assistance.

Cheers! 🎈 🎂 🎁 🎉 😸 Let's enjoy our newfound 16 million colors! 🌈 And long live tmux! 👑

P.S. I wrote up a little story about all this (along with usage instructions, of course) on my blog. 📝

[jfelchner]

@sunaku absolutely right! Tmux is a tool that I use every single day and it's work like this (and continued support by @nicm, @ThomasAdam and others) that makes it continue to stay relevant and immune to the temptation for people to create forks or other competitors touting "It's like Tmux but it does x".

I'm waiting for the actual stable release to use this, but I'm extremely excited. :) @nicm any idea when the next release is going out?

[ThomasAdam]

On 30 January 2016 at 21:23, Jeff Felchner notifications@github.com wrote:

I'm waiting for the actual stable release to use this, but I'm extremely
excited. :) @nicm https://github.com/nicm any idea when the next
release is going out?

I release the portable version to coincide with OpenBSD releases. The next
one is in May.

-- Thomas Adam

[alexlafroscia]

Just a note for anyone that uses Homebrew and wants to install this patch; you can do so by uninstalling Tmux:

$ brew uninstall tmux

editing the formula for Tmux

$ brew edit tmux

and comment out references to the Bash completion files on lines 46 and 47, since the examples/ directory no longer exists. Then you can install Tmux again from master using

$ brew install tmux --HEAD

which will grab the latest commit. Of course, only do this if you're OK with using the development version of Tmux.

[jfelchner]

@ThomasAdam thank you.
@alexlafroscia that'll work for me. Gracias. :)

[HeroCC]

Will this PR be included in 2.2? Or is it already in 2.1?

[jfelchner]

@HeroCC it'll be released in the next release whatever number happens to be.

[assaf758]

While trying 24bit-color support, I noticed there is some issue (when comparing to non-tmux terminal) - see http://ibin.co/2YAmCLcoBNRC.
Happens with two tests (see below) and two terminals (termite and gnome-terminal):
https://raw.githubusercontent.com/robertknight/konsole/master/tests/color-spaces.pl
https://github.com/gnachman/iTerm2/blob/master/tests/24-bit-color.sh

[alerque]

@assaf758 You should open a separate issue report for this. This PR covered the initial implementation but if there are bugs now that it has been merged they should be reported separately. When you do please include more information about your setup including the exact commit you compiled TMUX from and what version of the terminals you are using. I am unable to replicate this using those same scripts and Termite as my terminal, so something very specific to your setup is broken and we'll need more details to track it down.

[neon64]

I'm not sure if this is the correct place to ask, so apologies in advance... but does this patch include support for 24-bit colour within tmux.conf as well? I tried using '00ff00' as a colour, for example, but that didn't work.

[lock]

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.