George Nachman / iterm2

Comment 1 by gnach... on October 07, 2010 16:17

Do any apps support this? Besides that, my only reservation is that it would increase memory usage nontrivially.

Labels: ~~Type: Defect~~, Type: Enhancement

Comment 2 by doerwal... on October 13, 2010 10:30

http://cheat.errtheblog.com/s/terminal_escapes/ states that "24-bit Color codes appear only appear to be implemented for Konsole (a KDE / Linux Terminal Emulator)". I know of no applications that uses 24bit (although I would immediate start to use those escape sequences in my own shell scripts ;)). Furthermore I don't know if curses supports 24bit mode.

Comment 3 by gnach... on November 24, 2010 05:48

(No comment has been entered for this change)

Labels: ~~Priority: Medium~~, Priority: Low

Comment 4 by jonathan.eun... on September 01, 2012 18:26

It's true that only Konsole supports that 24-bit color mode so far (AFAIK). The problem is, without support for this, we're stuck with the 8-bit color cube, which is pretty meager. It has, for instance, no nice dark green. And it's not well-organized. There's no easy/good way to use human-sensible color names (say of the X11 variety (http://bradbury.org/jim/xtermcolors.html) or the even more important RGB values specified for web programming (in HTML or CSS). Given today's emphasis on Web output, this inability for developers to easily translate to terminal color values means that colored terminal text is even less likely to be supported by applications.

I do not see memory consumption to be a major impediment, given modern system RAM sizes. But if you think it's an issue, use a CLUT (color lookup table) approach. It's highly unlikely that any real terminal app would ever use more than 256 colors. It's just that the 256 colors in the classical 8-bit ANSI set suck badly, and correlate so poorly to the colors used in other apps. It appears from iterm2's loadable color profiles (http://code.google.com/p/iterm2/wiki/ColorGallery) that it already supports 24b definitions, just not as a part of program output.

So yes, please dollow Konsole's extension to 24b colors.

Comment 5 by jonathan.eun... on September 01, 2012 18:27

s/dollow/follow/g

Comment 6 by oth... on June 07, 2013 16:50

Vim has a custom build supports 24bit color[1] by ZyX.
A thinks Vim users will be very glad to have full color Vim theme shows on their screen.

http://usevim.com/2013/05/31/24bit/

Comment 7 by docw... on June 08, 2013 19:20

My understanding is that konsole just takes the RGB tuple escape sequence and instead of getting the nearest, it just uses it directly. From http://search.cpan.org/~sharyanto/Color-ANSI-Util-0.01/lib/Color/ANSI/Util.pm#rgb_to_ansi256($color)_=>_STR

BTW, ANSI code to set RGB foreground color (supported by Konsole/Yakuake): "\e[38;2;;;m" and to set RGB background color: "\e[48;2;;;m", where R, G, B are decimal values.

Comment 8 by gnach... on June 24, 2013 00:47

(No comment has been entered for this change)

Labels: Milestone: Release3.0

Comment 9 by fxb... on September 05, 2013 11:06

Is this feature request being considered. It would be a really big win for emacs people.

Comment 10 by gnach... on September 09, 2013 05:29

This is in the nightly build now!

Status: Fixed

Comment 11 by u...@zuse.jp on September 09, 2013 17:19

I think konsole style 3-byte color mode (separated by semi-colon) is harmful.
If you want to support 24bit color with SGR sequence, the proper way is to use colon separator (ITU T.416 style).

The Konsole-style SGR sequence breaks backword and forward compatibility.

It is clear that a Konsole-style sequence causes incorrect action on many terminals that do not support it. In contrast, ITU T.416-style's one is expected to be ignored by ideal ECMA-48 based terminals (that have canonical control function parser).

And the Konsole style introducer "CSI 38/48 ; n ;" takes variable length arguments, so this sequence can not extend safely. Actually, current iTerm2's parser causes bad action when CMY/CMYK sequences. Imagine the hardness of when someone propose a extension for YUV/HLS, with keeping backward compatibility. A future terminal developer may curse us.

In that sense, the same can be said of xterm's 256-color extension (CSI 38 ; 5 ; n / CSI 48 ; 5 ; n). But that has already spread widely. We should not repeat the same mistake.

Comment 12 by fxb... on September 10, 2013 07:41

Taking advantage of this feature under emacs would be really great. I launched a thread on emacs-devel
http://lists.gnu.org/archive/html/emacs-devel/2013-09/msg00157.html

Comment 13 by patrick.osc... on September 14, 2013 23:08

As a Vim user i am raring to use true color in iTerm. Great to see that there's something happening in this direction!

I downloaded the nightly build and used the perl script linked to in the first post here to test it. Didn't seem to work for me. Do I have to enable it first somehow?

Comment 14 by gnach... on September 17, 2013 21:16

@zuse.jp, do any other terminals implement the ITU standard? Also, can you give me an example of the bad CMY/CMYK sequence?

Comment 15 by gnach... on September 17, 2013 21:17

@patrick, what do you see? It should just work.

Comment 16 by sait... on October 15, 2013 15:41

@gnachman, I'm sorry for late reply.

do any other terminals implement the ITU standard?

AFAIK, the following terminals can parse ITU-T.416 style(colon separated) SGR sequence.

- xterm
- TeraTerm http://ttssh2.sourceforge.jp/index.html.en
- RLogin http://nanno.dip.jp/softlib/man/rlogin/ctrlcode.html (Japanese)
- mlterm http://ttssh2.sourceforge.jp/index.html.en

(For more details, see https://github.com/gnachman/iTerm2/blob/master/VT100Terminal.m#L647)

Also, can you give me an example of the bad CMY/CMYK sequence?

Now we print "foreground color CMY [38,2,100] and background CMYK [48,5,7,4]" in konsole-styled sequence.

echo -en "\033[38;3;38;2;255;48;4;48;5;7;4mabc"

It may bring hell to us.
Current iTerm2 interpret this as "foreground RGB [2,255,48], indexed background color 7 and underlined attribute".
gnome-terminal will interpret this as "half-bright, inverse, and underlined".

I do not know why we need to repeat the confusion of 15 years ago.
I prefer to abandon SGR sucks and propose new ECMA-48 compliant sequence, such as

CSI ? R ; G ; B $ m

Comment 17 by gnach... on November 11, 2013 06:36

Thanks for the clarification. This is quite a mess. I added support for the : delimiters in 52941309. I think I should keep support for the ; method since xterm supports it, which means people will expect it to work.

Comment 18 by jszakmeis... on July 07, 2014 12:02

Is this still supported in the nightly build? I ask because it doesn't seem to be. :-( I'm using iTerm2 1.0.0.20140629 currently.

Comment 19 by gnach... on July 09, 2014 02:33

This is in the nightly only. 20140629 is a v2 release candidate, while the nightly builds are on the v3 track.

Comment 20 by ja...@opsmanager.com on July 10, 2014 02:58

I'm looking at the Emacs xterm.el (intending to patch it in anticipation of official support)

How can I identify that iTerm2 terminal supports 24bit mode?

Comment 21 by ja...@opsmanager.com on July 10, 2014 03:15

Never mind: http://emacs.1067599.n5.nabble.com/RFC-Add-tty-True-Color-support-td299962.html

Comment 22 by gnach... on July 14, 2014 04:08

If a protocol for declaring support for 24-bit color emerges, I'd be glad to support it. I'd think it belongs in terminfo, though.

Comment 23 by gnach... on July 14, 2014 04:08

If a protocol for declaring support for 24-bit color emerges, I'd be glad to support it. I'd think it belongs in terminfo, though.

Support for 3-byte color mode