GNU bug report logs -
#44950
28.0.50; 24-bit colors not used in terminal with emacsclient
Previous Next
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.
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):
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):
> 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):
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):
[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: 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):
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: 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):
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):
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):
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):
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):
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):
[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: 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):
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: 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.