[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#39733: 26.3; Unclear direct color mode documentation can cause loadi

From: Eli Zaretskii
Subject: bug#39733: 26.3; Unclear direct color mode documentation can cause loading delays
Date: Sat, 22 Feb 2020 09:56:38 +0200

> From: Daniel Long Sockwell <address@hidden>
> Date: Fri, 21 Feb 2020 21:36:05 -0500
> > Emacs can be invoked with a custom definition as shown below
> >>     $ cat terminfo-24bit.src
> >>     
> >>     # Use colon separators.
> >>     xterm-24bit|xterm with 24-bit direct color mode,
> >>       use=xterm-256color,
> >>       setb24=\E[48:2:%p1%{65536}%/%d:%p1%{256}%/%{255}%&%d:%p1%{255}%&%dm,
> >>       setf24=\E[38:2:%p1%{65536}%/%d:%p1%{256}%/%{255}%&%d:%p1%{255}%&%dm,
> >>     # Use semicolon separators.
> >>     xterm-24bits|xterm with 24-bit direct color mode,
> >>       use=xterm-256color,
> >>       setb24=\E[48;2;%p1%{65536}%/%d;%p1%{256}%/%{255}%&%d;%p1%{255}%&%dm,
> >>       setf24=\E[38;2;%p1%{65536}%/%d;%p1%{256}%/%{255}%&%d;%p1%{255}%&%dm,
> >>     
> >>     $ tic -x -o ~/.terminfo terminfo-24bit.src
> >>     
> >>     $ TERM=xterm-24bit emacs -nw
> Source: Emacs FAQ, 5.3
> I followed these directions literally, and enabled direct color support
> in Emacs, apparently without issue.  However, what I did not realize was
> that I ought *not* to have followed the example literally – instead, I
> should have replaced "xterm" with my actual $TERM value.

If the terminfo entry uses xterm-24bits, then you _do_ have to use
xterm-24bit as the value of TERM.  If you want any other terminal, the
terminfo entry should have a different name.  The example shows it for

> Months later, I realized that I was experiencing a very odd bug: my
> Emacs instance was taking well over 2 seconds to start in a terminal,
> even when invoked with `emacs -Q -nw`.  Even more oddly, I determined
> `M-x emacs-init-time` showed a very low time – whatever was causing the
> slowdown was outside of the normal init process.  After fairly extensive
> testing, I discovered that the slowdown was caused by a pselect
> timeout.  This one, according to strace:
> > pselect6(5, [4], [], NULL, {tv_sec=1, tv_nsec=998526670}, {NULL, 8}) =
> > 0 (Timeout) <2.000940>
> After even more testing, I determined that the issue was caused by the
> terminfo/$TERM settings: apparently, if the user has a $TERM value that
> does not match their terminal, Emacs will have a 2-second delay before
> launching, waiting for whatever that pselect call is looking for.

That's because for xterm we support additional features, unrelated to
colors, which need to be probed at startup.  The probe sends a special
control sequence to the terminal, and then waits for the response with
a 2 sec timeout.  Your terminal doesn't support those control
sequences, so it seems, so you get the timeout.

> Once I finally figured the above out, I decided to file this bug in the
> hope that the documentation can be updated and other can avoid spending
> as long with this issue as I did.

The latest version of the Emacs FAQ already says at the end of this

     If your terminal is incompatible with XTerm, you may have to use
  another ‘TERM’ definition.  Any terminal whose name includes ‘direct’
  should be a candidate.  The ‘toe’ command can be used to find out which
  of these are installed on your system:

       $ toe | grep '\-direct'

       konsole-direct  konsole with direct-color indexing
       vte-direct      vte with direct-color indexing
       st-direct       st with direct-color indexing
       xterm-direct2   xterm with direct-color indexing (old)
       xterm-direct    xterm with direct-color indexing

     Terminals with ‘RGB’ capability treat pixels #000001 - #000007 as
  indexed colors to maintain backward compatibility with applications that
  are unaware of direct color mode.  Therefore the seven darkest blue
  shades may not be available.  If this is a problem, you can always use
  custom terminal definition with ‘setb24’ and ‘setf24’.

Given this addition, do you see anything else that needs to be changed
in the FAQ?


reply via email to

[Prev in Thread] Current Thread [Next in Thread]