bug#74252: 31.0.50; multi-tty;: init_tty using getenv for COLORTERM

["Gerd Möllmann" <gerd.moellmann@gmail.com>]

Just copying parts of messages from emacs-devel.

----------

I was playing with multi-tty today, and I encountered strange behavior.
For example, using 2 terminals that have different capabilties, say
different TERM and/or COLORTERM, does not really work.

Informal example: I start an emacs server -nw in iTerm
(TERM=xterm-256color, COLORTERM=truecolor), then emacsclient --tty in a
Terminal window (TERM=xterm, COLORTERM not set) => The Emacs frame in
the Terminal window is obviously confused about the terminal's
color capabilties.

----------

Something is fishy here. AFAICS, emacsclient sends its environment to
the server before it opens a frame in the server, which is done with
server-create-tty-frame.

  (defun server-create-tty-frame (tty type proc &optional parameters)
    (unless tty
      (error "Invalid terminal device"))
    (unless type
      (error "Invalid terminal type"))
    (let ((frame
           (server-with-environment
               (process-get proc 'env)
               '("LANG" "LC_CTYPE" "LC_ALL"
                 ;; For tgetent(3); list according to ncurses(3).
                 "BAUDRATE" "COLUMNS" "ESCDELAY" "HOME" "LINES"
                 "NCURSES_ASSUMED_COLORS" "NCURSES_NO_PADDING"
                 "NCURSES_NO_SETBUF" "TERM" "TERMCAP" "TERMINFO"
                 "TERMINFO_DIRS" "TERMPATH"
                 ;; rxvt wants these
                 "COLORFGBG" "COLORTERM")
             (server--create-frame
              ;; Ignore nowait here; we always need to
              ;; clean up opened ttys when the client dies.
              nil proc
              `((window-system . nil)
                (tty . ,tty)
                (tty-type . ,type)
                ,@parameters)))))

      ;; ttys don't use the `display' parameter, but callproc.c does to set
      ;; the DISPLAY environment on subprocesses.
      (set-frame-parameter frame 'display
                           (getenv-internal "DISPLAY" (process-get proc 'env)))
      frame))

The (process-get proc 'env) should contain what emacsclient sent for the
enviroment. That apparently doesn't work as expected. Many calls stacks
down in make-frame -> ... -> make_terminal_frame -> init_tty Emacs uses
C getenv, and that doesn't return what I suspect server-with-environment
was intended for.

In the case I described, COLORTERM is still truecolor as it was when the
server was started. I wonder what is used when Emacs is used as a
daemon, hm.  Probably getenv returns NULL, at least on macOS/launchd.

----------

> They do, but then they change the settings in the per-terminal
> tty_display_info, no? Or am I misreading init_tty? Certainly
>
> TERM=xterm-mono emacsclient -tty
>
> gives me a mono emacs.

And TERN works because emacsclient picks it up and sends its value as
part of the frame creation command to the server. In the server, it is
then passed down to make_terminal_frame as a frame parameter which
itself uses it for init_tty.

A pretty easy fix would be to make the environment that we got from
emacsclient anyway another frame parameter. Then init_tty wouldn't have
to use getenv to get the value of COLORTERM.