After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 778958 - Truecolors: setf24/setb24 - what to do?
Truecolors: setf24/setb24 - what to do?
Status: RESOLVED OBSOLETE
Product: vte
Classification: Core
Component: general
git master
Other Linux
: Normal enhancement
: ---
Assigned To: VTE Maintainers
VTE Maintainers
Depends on:
Blocks:
 
 
Reported: 2017-02-20 13:23 UTC by Egmont Koblinger
Modified: 2021-06-10 15:19 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Egmont Koblinger 2017-02-20 13:23:35 UTC
When S-Lang implemented truecolor support, they went for checking the COLORTERM variable because ncurses/terminfo's author had expressed earlier that he has no desire making a terminfo capability for this feature.

Correspondingly, VTE started to export this variable: bug 754521.

Then recently emacs added support for truecolors. They decided to introduce a terminfo feature, which I believe is a much nicer approach than COLORTERM.

See http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=e463e57 for the change, and https://gist.github.com/XVilka/8346728#gistcomment-2004505 for a pointer to their mailing list discussions (I haven't read that).

If you follow the instructions from the raw git diff, don't forget to remove the @ characters, they are the autogenerated doc's escape character, shouldn't appear in the terminfo definition.

To verify that you've successfully created the terminfo definitions, do something like

$ TERM=xterm-24bits tput setf24 65555 | cat -v
^[[38;2;1;0;19m  # this is the expected output

Note that, presumably for weird compability issues, "tput colors" still reports 256.

I find it an absolute overengineering that they define "xterm-24bit" with colon separator and "xterm-24bits" with semicolon. I can never remember whether the 256 color version is singular "xterm-256color" or plural "xterm-256colors", they make it here more complicated by the trailing "s" standing for "s"emicolon rather than plural. IMO they should only have one version, name it "xterm-24bit" to be consistent with the existing naming convention, and emit semicolons to be consistent with the 256-color setaf/setab and to make it work on more terminals. Nevermind.

Now the big question is: What's next?

We can wait for a few years to see what happens. Will the main distros patch their terminfo package to add support for this? Will maybe terminfo's maintainer change his mind and include this change? Or we can even push for these changes.

Then, at some point, we could change our default.

Or could we right now go ahead and see if xterm-24bit is available, and if so, use that? I wouldn't want to re-introduce the ncurses (libtinfo) dependency that we dropped in 0.38-ish, but I'd be fine with simply checking for the existance of this file at a few standard locations. The only problem would be if you ssh to a remote machine which does not have this.

Or should we again consider deviating from xterm and shipping/maintaining our own terminfo description (and keep asking official terminfo to keep this updated? - ouch!) Apart from truecolors, this would also be useful with the extended mouse coordinates. Terminfo introduced xterm-extmouse or something like that recently, using the 1006 extension, but only 16 colors. For some reason that I'll never be able to understand, the maintainer refuses to create a description that contains 256 colors and extended mouse, and refuses to make extended mouse the default.

At this moment my primary aim is to keep a record of this and see what's happening in the world. We defaulted to TERM=xterm for quite a while when 256-color support was already quite widespread and terminfo description was presumably available pretty much everywhere. Maybe it's fine to wait a bit with truecolor as well...
Comment 1 Egmont Koblinger 2017-02-20 17:13:08 UTC
Terminfo capabilities can take multiple parameters (e.g. obviously at least two parameters are required for cursor positioning "cup"). As such, I'm wondering why emacs folks chose to have a single parameter encoding all three color components (65536*R+256*B+G), rather than three separate parameters:

xterm-24bits|xterm with 24-bit direct color mode,
  use=xterm-256color,
  setb24=\E[48;2;%p1%d;%p2%d;%p3%dm,
  setf24=\E[38;2;%p1%d;%p2%d;%p3%dm,

$ TERM=xterm-24bits tput setf24 1 0 19 | cat -v
^[[38;2;1;0;19m

I believe it's a much nicer interface to expose.
Comment 2 Egmont Koblinger 2017-02-20 17:20:18 UTC
Obvious typo is obvious: 65536*R+256*G+B
Comment 3 Christian Persch 2017-02-20 19:20:00 UTC
There's no bug / emacs bug tracker for this that I could find, but it was discussed on the emacs-devel ML (didn't read it through, only found it there :-).

As for terminfo/ncurses, truecolour support was quite definitively rejected, and it has just been reiterated in this current thread [https://lists.gnu.org/archive/html/bug-ncurses/2017-02/msg00018.html] on the ncurses ML. Now, there appears to be much frustration about this all around, so it might be possible to get all the non-ncurses people working together on a solution?

Installing our own terminfo definition still has all the old problems that kept us from updating to xterm-256color for so long, so I don't think that's the best solution. If only terminfo/ncurses had fallbacks... 

(BTW, the colon form is the only one that should be used, ever :-)
Comment 4 Egmont Koblinger 2017-02-20 19:38:13 UTC
Saw that ncurses thread, responded to this month's initial mail there trying to second the request, got rejected: "Your message was deemed inappropriate by the moderator."

I feel a generic frustration and hatred from Thomas towards VTE or me in particular, not just in this topic. Honestly no clue why. It wasn't so a year or two ago.

> Now, there appears to be much frustration about this all around, so it might be possible to get all the non-ncurses people working together on a solution?

We should definitely try to do this. I don't know where to start, though, what forum to use for a discussion that gathers together developers of key terminal emulators, libraries, application and popular distributions. Any suggestion?
Comment 5 GNOME Infrastructure Team 2021-06-10 15:19:17 UTC
-- GitLab Migration Automatic Message --

This bug has been migrated to GNOME's GitLab instance and has been closed from further activity.

You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/vte/-/issues/2376.