bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[tastytea via Bug reports for GNU Emacs, the Swiss army knife of text editors]

When emacs is started as daemon by an init system (without COLORTERM
set), emacsclient -t only has 256 colors if TERM="tmux-256color" and
COLORTERM="truecolor".
When the daemon is started with COLORTERM="truecolor" everything is
fine (thanks to the patch in bug #41846).
tmux has no -direct or -24 bit terminal definition.

To reproduce:
* Start daemon: COLORTERM="" emacs --fg-daemon
* Start emacsclient:
  TERM="tmux-256color" COLORTERM="truecolor" emacsclient -t

In GNU Emacs 28.0.50 (build 1, x86_64-pc-linux-gnu, GTK+ Version
3.24.22, cairo version 1.16.0) of 2020-11-29 built on localhost
Repository revision: 38ed05f49fcfe7c6d6908041010881a04a7ff6b1
Repository branch: master
System Description: Gentoo/Linux

Configured using:
 'configure --prefix=/usr --build=x86_64-pc-linux-gnu
 --host=x86_64-pc-linux-gnu --mandir=/usr/share/man
 --infodir=/usr/share/info --datadir=/usr/share --sysconfdir=/etc
 --localstatedir=/var/lib --disable-silent-rules
 --docdir=/usr/share/doc/emacs-28.0.9999
 --htmldir=/usr/share/doc/emacs-28.0.9999/html --libdir=/usr/lib64
 --program-suffix=-emacs-28-vcs --includedir=/usr/include/emacs-28-vcs
 --infodir=/usr/share/info/emacs-28-vcs --localstatedir=/var
 --enable-locallisppath=/etc/emacs:/usr/share/emacs/site-lisp
 --without-compress-install --without-hesiod --without-pop
 --with-file-notification=inotify --with-pdumper --enable-acl
 --with-dbus --with-modules --without-gameuser --with-libgmp --with-gpm
 --with-json --without-kerberos --without-kerberos5 --with-lcms2
 --with-xml2 --without-mailutils --without-selinux --with-gnutls
 --without-libsystemd --with-threads --without-wide-int --with-zlib
 --with-sound=no --with-x --without-ns --without-gconf
 --without-gsettings --without-toolkit-scroll-bars --with-gif
 --with-jpeg --with-png --with-rsvg --with-tiff --with-xpm
 --without-imagemagick --with-xft --with-cairo --with-harfbuzz
 --without-libotf --without-m17n-flt --with-x-toolkit=gtk3
 --with-xwidgets --with-dumping=pdumper 'CFLAGS=-march=native -O2 -pipe'
 CPPFLAGS= 'LDFLAGS=-Wl,-O1 -Wl,--as-needed''

Configured features:
XPM JPEG TIFF GIF PNG RSVG CAIRO GPM DBUS GLIB NOTIFY INOTIFY ACL GNUTLS
LIBXML2 FREETYPE HARFBUZZ ZLIB GTK3 X11 XDBE XIM MODULES THREADS
XWIDGETS JSON PDUMPER LCMS2

Important settings:
  value of $LC_MESSAGES: en_US.utf8
  value of $LC_TIME: en_DK.UTF-8
  value of $LANG: de_DE.utf8
  value of $XMODIFIERS: @im=ibus
  locale-coding-system: utf-8-unix

Major mode: GFM

Minor modes in effect:
  midnight-mode: t
  counsel-projectile-mode: t
  projectile-mode: t
  treemacs-filewatch-mode: t
  treemacs-follow-mode: t
  treemacs-git-mode: deferred
  treemacs-fringe-indicator-mode: t
  global-git-commit-mode: t
  which-key-mode: t
  editorconfig-mode: t
  async-bytecomp-package-mode: t
  shell-dirtrack-mode: t
  global-atomic-chrome-edit-mode: t
  volatile-highlights-mode: t
  display-fill-column-indicator-mode: t
  flyspell-mode: t
  whitespace-mode: t
  doom-modeline-mode: t
  global-company-mode: t
  company-mode: t
  global-flycheck-mode: t
  flycheck-mode: t
  which-function-mode: t
  electric-pair-mode: t
  ruler-mode: t
  save-place-mode: t
  all-the-icons-ivy-rich-mode: t
  ivy-rich-mode: t
  ivy-mode: t
  global-display-line-numbers-mode: t
  display-line-numbers-mode: t
  global-hl-line-mode: t
  show-paren-mode: t
  purpose-mode: t
  delete-selection-mode: t
  global-auto-revert-mode: t
  savehist-mode: t
  override-global-mode: t
  straight-use-package-mode: t
  straight-package-neutering-mode: t
  tooltip-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Load-path shadows:
/home/tastytea/.emacs.d/straight/build/dash/dash hides
/usr/share/emacs/site-lisp/dash/dash
/home/tastytea/.emacs.d/straight/build/dash-functional/dash-functional
hides /usr/share/emacs/site-lisp/dash/dash-functional
/home/tastytea/.emacs.d/straight/build/f/f hides
/usr/share/emacs/site-lisp/f/f
/home/tastytea/.emacs.d/straight/build/lua-mode/init-tryout hides
/usr/share/emacs/site-lisp/lua-mode/init-tryout
/home/tastytea/.emacs.d/straight/build/lua-mode/lua-mode hides
/usr/share/emacs/site-lisp/lua-mode/lua-mode
/home/tastytea/.emacs.d/straight/build/s/s hides
/usr/share/emacs/site-lisp/s/s
/home/tastytea/.emacs.d/straight/build/with-editor/with-editor hides
/usr/share/emacs/site-lisp/with-editor/with-editor
/home/tastytea/.emacs.d/straight/build/eldoc/eldoc hides
/usr/share/emacs/28.0.50/lisp/emacs-lisp/eldoc
/home/tastytea/.emacs.d/straight/build/let-alist/let-alist hides
/usr/share/emacs/28.0.50/lisp/emacs-lisp/let-alist

Features:
(shadow sort editorconfig-core editorconfig-core-handle
editorconfig-fnmatch mail-extr mc-hide-unmatched-lines-mode mc-mark-more
mc-cycle-cursors multiple-cursors-core rect windmove cl-print mailalias
help-fns radix-tree mwim emacsbug mule-util midnight tab-line ox-md
ox-odt rng-loc rng-uri rng-parse rng-match rng-dt rng-util rng-pttrn
nxml-parse nxml-ns nxml-enc xmltok nxml-util ox-latex ox-icalendar
ox-html table ox-ascii ox-publish ox org-element avl-tree ob-C ob-shell
org ob ob-tangle ob-ref ob-lob ob-table ob-exp org-macro org-footnote
org-src ob-comint org-pcomplete org-list org-faces org-entities
org-version ob-emacs-lisp ob-core ob-eval org-table ol org-keys
org-compat org-macs org-loaddefs cal-menu calendar cal-loaddefs smtpmail
sendmail hideshow counsel-projectile treemacs-projectile projectile grep
treemacs treemacs-header-line treemacs-compatibility treemacs-mode
treemacs-interface treemacs-extensions treemacs-persistence
treemacs-mouse-interface treemacs-tag-follow-mode
treemacs-filewatch-mode treemacs-tags treemacs-follow-mode
treemacs-rendering t

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Eli Zaretskii]

> Date: Sun, 29 Nov 2020 16:56:41 +0100
> Jabber-ID: tastytea@tastytea.de
> From: tastytea via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> 
> When emacs is started as daemon by an init system (without COLORTERM
> set), emacsclient -t only has 256 colors if TERM="tmux-256color" and
> COLORTERM="truecolor".
> When the daemon is started with COLORTERM="truecolor" everything is
> fine (thanks to the patch in bug #41846).
> tmux has no -direct or -24 bit terminal definition.
> 
> To reproduce:
> * Start daemon: COLORTERM="" emacs --fg-daemon
> * Start emacsclient:
>   TERM="tmux-256color" COLORTERM="truecolor" emacsclient -t

Isn't this a problem with the terminfo description of tmux?

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[tastytea via Bug reports for GNU Emacs, the Swiss army knife of text editors]

On 2020-11-29 20:47+0200 Eli Zaretskii <eliz@gnu.org> wrote:

> > Date: Sun, 29 Nov 2020 16:56:41 +0100
> > Jabber-ID: tastytea@tastytea.de
> > From: tastytea via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
> > 
> > When emacs is started as daemon by an init system (without COLORTERM
> > set), emacsclient -t only has 256 colors if TERM="tmux-256color" and
> > COLORTERM="truecolor".
> > When the daemon is started with COLORTERM="truecolor" everything is
> > fine (thanks to the patch in bug #41846).
> > tmux has no -direct or -24 bit terminal definition.
> > 
> > To reproduce:
> > * Start daemon: COLORTERM="" emacs --fg-daemon
> > * Start emacsclient:
> >   TERM="tmux-256color" COLORTERM="truecolor" emacsclient -t  
> 
> Isn't this a problem with the terminfo description of tmux?

I have the same problem with xfce4-terminal, rxvt-unicode and
alacritty. I can make it work in xfce4-terminal and alacritty by
setting TERM="xterm-direct" and ncurses-6.2-p20201003 has added support
for tmux-direct, but it doesn't just work.

And since emacs uses COLORTERM, I thought emacsclient could do the same?

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Tim Ruffing]

[-- Attachment #1: Type: text/plain, Size: 759 bytes --]

I think what tastytea is saying is that when emacs checks the env
variable COLORTERM, it uses the environment of the server and not the
one of emacsclient. And yes, that's just a bug. emacsclient should read
that variable and pass it to server. But this requires new code because
it breaks with the pattern of using terminfo to detect term support.

So the terminfo detection is currently more reliable. Would you be
willing to accept something like the attached patch? This will improve
detection without relying on COLORTERM, which should make the situation
already much better. Tc is in the terminfo of many terminals, see
https://gist.github.com/XVilka/8346728 .

If yes, I can send an improved patch (with added explanations to
doc/misc/efaq.texi).

Tim

[-- Attachment #2: 0001-Support-Tc-terminfo-flag-forg-24-bit-color-support-i.patch --]
[-- Type: text/x-patch, Size: 1340 bytes --]

From 8c5851a96447cd06f41d2983390e699461870072 Mon Sep 17 00:00:00 2001
From: Tim Ruffing <crypto@timruffing.de>
Date: Mon, 31 May 2021 15:38:19 +0200
Subject: [PATCH] Support Tc terminfo flag forg 24-bit color support in
 terminal

---
 src/term.c | 10 ++++++----
 1 file changed, 6 insertions(+), 4 deletions(-)

diff --git a/src/term.c b/src/term.c
index c995a4499c..fdcc116b69 100644
--- a/src/term.c
+++ b/src/term.c
@@ -4157,10 +4157,12 @@ init_tty (const char *name, const char *terminal_type, bool must_succeed)
 	       could return 32767.  */
 	    tty->TN_max_colors = 16777216;
 	  }
-	/* Fall back to xterm+direct (semicolon version) if requested
-	   by the COLORTERM environment variable.  */
-	else if ((bg = getenv("COLORTERM")) != NULL
-		 && strcasecmp(bg, "truecolor") == 0)
+	/* Fall back to xterm+direct (semicolon version) if Tc is set
+	   (de-facto standard introduced by tmux) or if	requested by
+	   the COLORTERM environment variable.  */
+	else if (tigetflag("Tc")
+		 || ((bg = getenv("COLORTERM")) != NULL
+		     && strcasecmp(bg, "truecolor") == 0))
 	  {
 	    tty->TS_set_foreground = "\033[%?%p1%{8}%<%t3%p1%d%e38;2;%p1%{65536}%/%d;%p1%{256}%/%{255}%&%d;%p1%{255}%&%d%;m";
 	    tty->TS_set_background = "\033[%?%p1%{8}%<%t4%p1%d%e48;2;%p1%{65536}%/%d;%p1%{256}%/%{255}%&%d;%p1%{255}%&%d%;m";
-- 
2.31.1

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Eli Zaretskii]

> From: Tim Ruffing <crypto@timruffing.de>
> Cc: 44950@debbugs.gnu.org
> Date: Mon, 31 May 2021 16:06:55 +0200
> 
> I think what tastytea is saying is that when emacs checks the env
> variable COLORTERM, it uses the environment of the server and not the
> one of emacsclient. And yes, that's just a bug. emacsclient should read
> that variable and pass it to server. But this requires new code because
> it breaks with the pattern of using terminfo to detect term support.
> 
> So the terminfo detection is currently more reliable. Would you be
> willing to accept something like the attached patch? This will improve
> detection without relying on COLORTERM, which should make the situation
> already much better. Tc is in the terminfo of many terminals, see
> https://gist.github.com/XVilka/8346728 .

That sounds like a kludge to me, of which we already have quite a few
there (the COLORTERM thing is already a kludge).  Do we really have to
add one more trick, just to paper over bad terminfo data?  Why don't
these terminals get their act together and fix their terminfo?

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Tim Ruffing]

For context: I'm coming from 
https://github.com/kovidgoyal/kitty/issues/1141#issuecomment-851289392
where the maintainer of kitty told me that they may be able to add a
kludge on their side but rather prefer to have it fixed on the emacs
side... And yeah, I understand both positions, noone wants to have ugly
code but I think someone needs to add it and emacs user would prefer
from this (not only in kitty but also in the rather common tmux).

But let me give you some more context. I think when emacs was changed
to support the RGB flag, it was believed that this is the right
("standard") way to do it. And this may be true if you ask ncurses but
apparently the maintainer hasn't been exactly helpful in the past [1].

The thing is that kitty had "RGB" in the terminfo but removed it again
and I think they're right. The way it's designed is just awful:
RGB is mutually exclusive with 256 color mode, so if you have RGB
applications like emacs and other applications that only support 256
colors (which exist out there), you need to set TERM depending on which
application you run. That's certainly not the idea of terminfo but
apparently this is how ncurses thinks RGB should be used and that's why
the ship with all the "-direct" terminfos [2]. But if the user needs to
set TERM anyway, what's the point of terminfos?  

So I can understand but I think the entire situation is just a big mess
and at this point some pragmatic solution is the best way forward...

By the way, it's interesting to see what others do. neovim's code in
fact has quirks for all the terminals [3]. Then "tc" sounds like the
easier option, and it's certainly a smaller hack than an env variable.

[1] https://lists.gnu.org/archive/html/bug-ncurses/2016-08/msg00036.html
[2] https://github.com/kovidgoyal/kitty/issues/1141#issuecomment-851289392
[3] https://github.com/neovim/neovim/blob/c46d9814619cee5183ea08989352d72fb9aaea5a/src/nvim/tui/tui.c#L1618

On Mon, 2021-05-31 at 19:19 +0300, Eli Zaretskii wrote:
> > From: Tim Ruffing <crypto@timruffing.de>
> > Cc: 44950@debbugs.gnu.org
> > Date: Mon, 31 May 2021 16:06:55 +0200
> > 
> > I think what tastytea is saying is that when emacs checks the env
> > variable COLORTERM, it uses the environment of the server and not the
> > one of emacsclient. And yes, that's just a bug. emacsclient should
> > read
> > that variable and pass it to server. But this requires new code
> > because
> > it breaks with the pattern of using terminfo to detect term support.
> > 
> > So the terminfo detection is currently more reliable. Would you be
> > willing to accept something like the attached patch? This will
> > improve
> > detection without relying on COLORTERM, which should make the
> > situation
> > already much better. Tc is in the terminfo of many terminals, see
> > https://gist.github.com/XVilka/8346728 .
> 
> That sounds like a kludge to me, of which we already have quite a few
> there (the COLORTERM thing is already a kludge).  Do we really have to
> add one more trick, just to paper over bad terminfo data?  Why don't
> these terminals get their act together and fix their terminfo?

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Eli Zaretskii]

> From: Tim Ruffing <crypto@timruffing.de>
> Cc: tastytea@tastytea.de, 44950@debbugs.gnu.org
> Date: Mon, 31 May 2021 18:45:38 +0200
> 
> So I can understand but I think the entire situation is just a big mess
> and at this point some pragmatic solution is the best way forward...

I'll let some other pragmatist to deal with this, because I'm too
disgusted by what we have there already (and I made most of those
changes).

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Lars Ingebrigtsen]

Tim Ruffing <crypto@timruffing.de> writes:

> So the terminfo detection is currently more reliable. Would you be
> willing to accept something like the attached patch? This will improve
> detection without relying on COLORTERM, which should make the situation
> already much better. Tc is in the terminfo of many terminals, see
> https://gist.github.com/XVilka/8346728 .
>
> If yes, I can send an improved patch (with added explanations to
> doc/misc/efaq.texi).

This does seem better than the current kludge, so I think we should go
ahead and apply it and see whether anybody complains.

So an updated patch (with efaq.texi amendments) would be welcome.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Lars Ingebrigtsen]

Lars Ingebrigtsen <larsi@gnus.org> writes:

> This does seem better than the current kludge, so I think we should go
> ahead and apply it and see whether anybody complains.
>
> So an updated patch (with efaq.texi amendments) would be welcome.

Tim, did you get any further on this issue?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Tim Ruffing]

Hi Lars, not yet. I'm currently on vacation, I'll come back to you in
about two weeks.

On Wed, 2021-07-21 at 14:05 +0200, Lars Ingebrigtsen wrote:
> Lars Ingebrigtsen <larsi@gnus.org> writes:
> 
> > This does seem better than the current kludge, so I think we should
> > go
> > ahead and apply it and see whether anybody complains.
> > 
> > So an updated patch (with efaq.texi amendments) would be welcome.
> 
> Tim, did you get any further on this issue?
> 

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Stefan Kangas]

Tim Ruffing <crypto@timruffing.de> writes:

> Hi Lars, not yet. I'm currently on vacation, I'll come back to you in
> about two weeks.
>
> On Wed, 2021-07-21 at 14:05 +0200, Lars Ingebrigtsen wrote:
>> Lars Ingebrigtsen <larsi@gnus.org> writes:
>>
>> > This does seem better than the current kludge, so I think we should
>> > go
>> > ahead and apply it and see whether anybody complains.
>> >
>> > So an updated patch (with efaq.texi amendments) would be welcome.
>>
>> Tim, did you get any further on this issue?

Just a friendly ping.  :-)

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Lars Ingebrigtsen]

Tim Ruffing <crypto@timruffing.de> writes:

> Hi Lars, not yet. I'm currently on vacation, I'll come back to you in
> about two weeks.

This was some months ago, so I went ahead and pushed the change to Emacs
29.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Tim Ruffing]

[-- Attachment #1: Type: text/plain, Size: 1962 bytes --]

Sorry for committing to send an updating patch but not replying for so
long...

Good that the broken patch was quickly fixed after it broke colors in
the macOS Terminal app. I looked again into the issue. One potential
further pitfall is that the Tc logic in tmux, which introduced the Tc
flag, is still different from what we do: while Tc is meant to mean
"support for the default sequences as in xterm+direct", tmux first
relies on the setrgbf/setrgbb escape sequences in the terminfo and only
provide the default sequences if setrgbf/setrgbb are not present.
 
I've attached a patch that would introduce full support for
setrgbf/setrgbb as previously proposed [2]. Before I propose an update
for the efaq.texi, let me know if you're interested in this patch (with
a proper commit messagea and NEWS entry) or not.

I personally don't care too much. With the Tc fix applied, Emacs works
for me, and believe our current code is fine, even though we don't
fully replicate tmux's logic respect to Tc. On the other hand, with
full support for setrgbf/setrgbb, we'd support pretty much every
existing method out there and the diff is not that large.

Best,
Tim



[1] See for example
https://github.com/tmux/tmux/commit/7eb496c00c313c2f8ab8debe6d154d5ac0db277b#diff-de4f90e163caf6cc83476898c795355523776a76f9ccc7783e9bd3a99fde671dR526
(this code was replaced later in 
https://github.com/tmux/tmux/commit/a6129e99749d2bbc8b4a991c7b5d09300aa55f39#
but the logic is still the same and the earlier commit is easier to
read). Another relevant discussion is
https://github.com/tmux/tmux/issues/2418 .

[2] https://lists.gnu.org/archive/html/bug-ncurses/2013-10/msg00007.html



On Thu, 2021-11-11 at 07:15 +0100, Lars Ingebrigtsen wrote:
> Tim Ruffing <crypto@timruffing.de> writes:
> 
> > Hi Lars, not yet. I'm currently on vacation, I'll come back to you in
> > about two weeks.
> 
> This was some months ago, so I went ahead and pushed the change to
> Emacs
> 29.
> 

[-- Attachment #2: 0001-Support-setrgbb-setrgbf-for-setting-24-bit-color.patch --]
[-- Type: text/x-patch, Size: 3501 bytes --]

From c296de5778f040e5803326dbb74a7362ac0146fa Mon Sep 17 00:00:00 2001
From: Tim Ruffing <crypto@timruffing.de>
Date: Fri, 12 Nov 2021 20:37:39 +0100
Subject: [PATCH] Support setrgbb/setrgbf for setting 24-bit color

---
 src/term.c     | 28 ++++++++++++++++++++++------
 src/termchar.h | 10 ++++++----
 2 files changed, 28 insertions(+), 10 deletions(-)

diff --git a/src/term.c b/src/term.c
index b4f3dfc25e..8022ca95f1 100644
--- a/src/term.c
+++ b/src/term.c
@@ -1945,7 +1945,10 @@ turn_on_face (struct frame *f, int face_id)
       ts = tty->standout_mode ? tty->TS_set_background : tty->TS_set_foreground;
       if (face_tty_specified_color (fg) && ts)
 	{
-          p = tparam (ts, NULL, 0, fg, 0, 0, 0);
+	  if (tty->TF_rgb_separate)
+	    p = tparam (ts, NULL, 0, fg >> 16, (fg >> 8) & 0xFF, fg & 0xFF, 0);
+	  else
+	    p = tparam (ts, NULL, 0, fg, 0, 0, 0);
 	  OUTPUT (tty, p);
 	  xfree (p);
 	}
@@ -1953,7 +1956,10 @@ turn_on_face (struct frame *f, int face_id)
       ts = tty->standout_mode ? tty->TS_set_foreground : tty->TS_set_background;
       if (face_tty_specified_color (bg) && ts)
 	{
-          p = tparam (ts, NULL, 0, bg, 0, 0, 0);
+	  if (tty->TF_rgb_separate)
+	    p = tparam (ts, NULL, 0, bg >> 16, (bg >> 8) & 0xFF, bg & 0xFF, 0);
+	  else
+	    p = tparam (ts, NULL, 0, bg, 0, 0, 0);
 	  OUTPUT (tty, p);
 	  xfree (p);
 	}
@@ -4133,10 +4139,10 @@ init_tty (const char *name, const char *terminal_type, bool must_succeed)
 
 #ifdef TERMINFO
       {
-	const char *fg = tigetstr ("setf24");
-	const char *bg = tigetstr ("setb24");
-	/* Non-standard support for 24-bit colors. */
-	if (fg && bg
+	const char *fg;
+	const char *bg;
+	/* Our own non-standard support for 24-bit colors. */
+	if ((fg = tigetstr ("setf24")) && (bg = tigetstr ("setb24"))
 	    && fg != (char *) (intptr_t) -1
 	    && bg != (char *) (intptr_t) -1)
 	  {
@@ -4144,6 +4150,16 @@ init_tty (const char *name, const char *terminal_type, bool must_succeed)
 	    tty->TS_set_background = bg;
 	    tty->TN_max_colors = 16777216;
 	  }
+	/* Other non-standard support for 24-bit colors. */
+	else if ((fg = tigetstr ("setrgbf")) && (bg = tigetstr ("setrgbb"))
+	    && fg != (char *) (intptr_t) -1
+	    && bg != (char *) (intptr_t) -1)
+	  {
+	    tty->TS_set_foreground = fg;
+	    tty->TS_set_background = bg;
+	    tty->TN_max_colors = 16777216;
+	    tty->TF_rgb_separate = 1;
+	  }
 	/* Standard support for 24-bit colors.  */
 	else if (tigetflag ("RGB") > 0)
 	  {
diff --git a/src/termchar.h b/src/termchar.h
index 7ab9337fbe..d266fd16f9 100644
--- a/src/termchar.h
+++ b/src/termchar.h
@@ -154,10 +154,12 @@ #define EMACS_TERMCHAR_H
   /* "op" -- SVr4 set default pair to its original value.  */
   const char *TS_orig_pair;
 
-  /* "AF"/"AB" or "Sf"/"Sb"-- set ANSI or SVr4 foreground/background color.
-     1 param, the color index.  */
-  const char *TS_set_foreground;
-  const char *TS_set_background;
+  const char *TS_set_foreground; /* "AF"/"Sf"/"setrgbf" -- set foreground color. */
+  const char *TS_set_background; /* "AB"/"Sb"/"setrgbb" -- set background color. */
+  /* If set, TS_set_foreground and TS_set_background take 3 separate
+     params for R, G, and B values ("setrgbf"/"setrgbb" -- non-standard).
+     If unset, they take 1 param ("AF"/"AB" or "Sf"/"Sb" -- ANSI or SVr4r). */
+  int TF_rgb_separate;
 
   int TF_hazeltine;             /* termcap hz flag. */
   int TF_insmode_motion;        /* termcap mi flag: can move while in insert mode. */
-- 
2.33.1

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Eli Zaretskii]

> From: Tim Ruffing <crypto@timruffing.de>
> Cc: tastytea <tastytea@tastytea.de>
> Date: Fri, 12 Nov 2021 20:44:54 +0100
> 
> I personally don't care too much. With the Tc fix applied, Emacs works
> for me, and believe our current code is fine, even though we don't
> fully replicate tmux's logic respect to Tc. On the other hand, with
> full support for setrgbf/setrgbb, we'd support pretty much every
> existing method out there and the diff is not that large.

I'm not sure I understand: if supporting "Tc" does the job, what does
the added code gain us?

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Tim Ruffing]

On Sat, 2021-11-13 at 17:10 +0200, Eli Zaretskii wrote:
> > I personally don't care too much. With the Tc fix applied, Emacs
> > works
> > for me, and believe our current code is fine, even though we don't
> > fully replicate tmux's logic respect to Tc. On the other hand, with
> > full support for setrgbf/setrgbb, we'd support pretty much every
> > existing method out there and the diff is not that large.
> 
> I'm not sure I understand: if supporting "Tc" does the job, what does
> the added code gain us?

Well, there are just (too) many standards and without setrgbf/setrgbb,
we don't support all of them. Even with support for Tc, there may be
terminals which can do 24bit but don't have Tc in their terminfo but
only setrgbf/setrgbb.

It's also possible (but very unlikely?) that they support only non-
"standard" escape sequences and thus can have setrgbf/setrgbb with non-
default sequences in terminfo but not Tc because the latter implies the
"standard" escape sequence. 

As I said, I believe the current code does the job. But still, I
wouldn't be surprised if next year some user proves me wrong and
complains here that 24bit doesn't work with their specific rare
terminal/terminfo while it works in other programs (which support
setrgbf/setrgbb).

bug#44950: 28.0.50; 24-bit colors not used in terminal with emacsclient

[Eli Zaretskii]

> From: Tim Ruffing <crypto@timruffing.de>
> Cc: larsi@gnus.org, 44950@debbugs.gnu.org, tastytea@tastytea.de
> Date: Tue, 16 Nov 2021 17:42:32 +0100
> 
> > I'm not sure I understand: if supporting "Tc" does the job, what does
> > the added code gain us?
> 
> Well, there are just (too) many standards and without setrgbf/setrgbb,
> we don't support all of them. Even with support for Tc, there may be
> terminals which can do 24bit but don't have Tc in their terminfo but
> only setrgbf/setrgbb.
> 
> It's also possible (but very unlikely?) that they support only non-
> "standard" escape sequences and thus can have setrgbf/setrgbb with non-
> default sequences in terminfo but not Tc because the latter implies the
> "standard" escape sequence. 

All of them are non-standard, and AFACT every terminal that supports
setrgbf/setrgbb also supports Tc.  So I think we should be good
supporting only some of the non-standard stuff there, at least for
now.  If and when some of these become standard terminfo capabilities,
we should support those standards ones first and foremost, of course.

> As I said, I believe the current code does the job. But still, I
> wouldn't be surprised if next year some user proves me wrong and
> complains here that 24bit doesn't work with their specific rare
> terminal/terminfo while it works in other programs (which support
> setrgbf/setrgbb).

Well, I think we should cross that bridge when we get to it.  And
maybe also clean up this area a bit when we do.

Thanks.