GNU bug report logs - #44950
28.0.50; 24-bit colors not used in terminal with emacsclient

Previous Next

Package: emacs;

Reported by: tastytea <tastytea <at> tastytea.de>

Date: Sun, 29 Nov 2020 17:35:02 UTC

Severity: normal

Tags: patch

Found in version 28.0.50

Fixed in version 29.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 44950 in the body.
You can then email your comments to 44950 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Sun, 29 Nov 2020 17:35:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to tastytea <tastytea <at> tastytea.de>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sun, 29 Nov 2020 17:35:02 GMT) Full text and rfc822 format available.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: tastytea <tastytea <at> tastytea.de>
To: bug-gnu-emacs <at> gnu.org
Subject: 28.0.50; 24-bit colors not used in terminal with emacsclient
Date: Sun, 29 Nov 2020 16:56:41 +0100
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





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Sun, 29 Nov 2020 18:49:02 GMT) Full text and rfc822 format available.

Message #8 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: tastytea <tastytea <at> tastytea.de>
Cc: 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50;
 24-bit colors not used in terminal with emacsclient
Date: Sun, 29 Nov 2020 20:47:45 +0200
> Date: Sun, 29 Nov 2020 16:56:41 +0100
> Jabber-ID: tastytea <at> tastytea.de
> From: tastytea via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Mon, 30 Nov 2020 00:38:03 GMT) Full text and rfc822 format available.

Message #11 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: tastytea <tastytea <at> tastytea.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50; 24-bit colors not used in terminal with
 emacsclient
Date: Sun, 29 Nov 2020 21:01:45 +0100
On 2020-11-29 20:47+0200 Eli Zaretskii <eliz <at> gnu.org> wrote:

> > Date: Sun, 29 Nov 2020 16:56:41 +0100
> > Jabber-ID: tastytea <at> tastytea.de
> > From: tastytea via "Bug reports for GNU Emacs,
> >  the Swiss army knife of text editors" <bug-gnu-emacs <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Mon, 31 May 2021 15:07:02 GMT) Full text and rfc822 format available.

Message #14 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Tim Ruffing <crypto <at> timruffing.de>
To: Eli Zaretskii <eliz <at> gnu.org>, tastytea <tastytea <at> tastytea.de>
Cc: 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50; 24-bit colors not used in terminal with
 emacsclient
Date: Mon, 31 May 2021 16:06:55 +0200
[Message part 1 (text/plain, inline)]
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
[0001-Support-Tc-terminfo-flag-forg-24-bit-color-support-i.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Mon, 31 May 2021 16:20:01 GMT) Full text and rfc822 format available.

Message #17 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tim Ruffing <crypto <at> timruffing.de>
Cc: tastytea <at> tastytea.de, 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50; 24-bit colors not used in terminal with
 emacsclient
Date: Mon, 31 May 2021 19:19:17 +0300
> From: Tim Ruffing <crypto <at> timruffing.de>
> Cc: 44950 <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Mon, 31 May 2021 16:46:01 GMT) Full text and rfc822 format available.

Message #20 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Tim Ruffing <crypto <at> timruffing.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tastytea <at> tastytea.de, 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50; 24-bit colors not used in terminal with
 emacsclient
Date: Mon, 31 May 2021 18:45:38 +0200
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 <at> timruffing.de>
> > Cc: 44950 <at> 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?






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Mon, 31 May 2021 17:06:02 GMT) Full text and rfc822 format available.

Message #23 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tim Ruffing <crypto <at> timruffing.de>
Cc: tastytea <at> tastytea.de, 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50; 24-bit colors not used in terminal with
 emacsclient
Date: Mon, 31 May 2021 20:04:40 +0300
> From: Tim Ruffing <crypto <at> timruffing.de>
> Cc: tastytea <at> tastytea.de, 44950 <at> 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).




Added tag(s) patch. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Sun, 06 Jun 2021 10:35:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Sun, 06 Jun 2021 10:37:01 GMT) Full text and rfc822 format available.

Message #28 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Tim Ruffing <crypto <at> timruffing.de>
Cc: tastytea <tastytea <at> tastytea.de>, Eli Zaretskii <eliz <at> gnu.org>,
 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50; 24-bit colors not used in terminal with
 emacsclient
Date: Sun, 06 Jun 2021 12:36:39 +0200
Tim Ruffing <crypto <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Wed, 21 Jul 2021 12:06:01 GMT) Full text and rfc822 format available.

Message #31 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Tim Ruffing <crypto <at> timruffing.de>
Cc: tastytea <tastytea <at> tastytea.de>, Eli Zaretskii <eliz <at> gnu.org>,
 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50; 24-bit colors not used in terminal with
 emacsclient
Date: Wed, 21 Jul 2021 14:05:29 +0200
Lars Ingebrigtsen <larsi <at> 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




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Wed, 21 Jul 2021 18:40:01 GMT) Full text and rfc822 format available.

Message #34 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Tim Ruffing <crypto <at> timruffing.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>
Cc: tastytea <tastytea <at> tastytea.de>, Eli Zaretskii <eliz <at> gnu.org>,
 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50; 24-bit colors not used in terminal with
 emacsclient
Date: Wed, 21 Jul 2021 18:39:22 +0000
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 <at> 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?
> 






Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Mon, 11 Oct 2021 12:35:01 GMT) Full text and rfc822 format available.

Message #37 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Kangas <stefan <at> marxist.se>
To: Tim Ruffing <crypto <at> timruffing.de>
Cc: tastytea <tastytea <at> tastytea.de>, Lars Ingebrigtsen <larsi <at> gnus.org>,
 Eli Zaretskii <eliz <at> gnu.org>, 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50;
 24-bit colors not used in terminal with emacsclient
Date: Mon, 11 Oct 2021 05:34:37 -0700
Tim Ruffing <crypto <at> 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 <at> 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.  :-)




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Thu, 11 Nov 2021 06:16:01 GMT) Full text and rfc822 format available.

Message #40 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Tim Ruffing <crypto <at> timruffing.de>
Cc: tastytea <tastytea <at> tastytea.de>, Eli Zaretskii <eliz <at> gnu.org>,
 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50; 24-bit colors not used in terminal with
 emacsclient
Date: Thu, 11 Nov 2021 07:15:36 +0100
Tim Ruffing <crypto <at> 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 marked as fixed in version 29.1, send any further explanations to 44950 <at> debbugs.gnu.org and tastytea <tastytea <at> tastytea.de> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Thu, 11 Nov 2021 06:16:02 GMT) Full text and rfc822 format available.

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Fri, 12 Nov 2021 19:46:02 GMT) Full text and rfc822 format available.

Message #45 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Tim Ruffing <crypto <at> timruffing.de>
To: Lars Ingebrigtsen <larsi <at> gnus.org>, Eli Zaretskii <eliz <at> gnu.org>, 
 44950 <at> debbugs.gnu.org
Cc: tastytea <tastytea <at> tastytea.de>
Subject: Re: bug#44950: 28.0.50; 24-bit colors not used in terminal with
 emacsclient
Date: Fri, 12 Nov 2021 20:44:54 +0100
[Message part 1 (text/plain, inline)]
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 <at> 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.
> 
[0001-Support-setrgbb-setrgbf-for-setting-24-bit-color.patch (text/x-patch, attachment)]

Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Sat, 13 Nov 2021 15:12:01 GMT) Full text and rfc822 format available.

Message #48 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tim Ruffing <crypto <at> timruffing.de>
Cc: tastytea <at> tastytea.de, larsi <at> gnus.org, 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50; 24-bit colors not used in terminal with
 emacsclient
Date: Sat, 13 Nov 2021 17:10:57 +0200
> From: Tim Ruffing <crypto <at> timruffing.de>
> Cc: tastytea <tastytea <at> 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?




Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Tue, 16 Nov 2021 16:43:02 GMT) Full text and rfc822 format available.

Message #51 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Tim Ruffing <crypto <at> timruffing.de>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: tastytea <at> tastytea.de, larsi <at> gnus.org, 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50; 24-bit colors not used in terminal with
 emacsclient
Date: Tue, 16 Nov 2021 17:42:32 +0100
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).





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#44950; Package emacs. (Tue, 16 Nov 2021 17:23:02 GMT) Full text and rfc822 format available.

Message #54 received at 44950 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Tim Ruffing <crypto <at> timruffing.de>
Cc: tastytea <at> tastytea.de, larsi <at> gnus.org, 44950 <at> debbugs.gnu.org
Subject: Re: bug#44950: 28.0.50; 24-bit colors not used in terminal with
 emacsclient
Date: Tue, 16 Nov 2021 19:22:04 +0200
> From: Tim Ruffing <crypto <at> timruffing.de>
> Cc: larsi <at> gnus.org, 44950 <at> debbugs.gnu.org, tastytea <at> 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.




bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Wed, 15 Dec 2021 12:24:05 GMT) Full text and rfc822 format available.

This bug report was last modified 2 years and 104 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.