Re: Multi-tty

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

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Thu, 07 Nov 2024 12:58:33 +0200, Eli Zaretskii <eliz@gnu.org> said:
>
>     >> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>     >> Date: Thu, 07 Nov 2024 10:53:09 +0100
>     >>
>     >> 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.)
>     >>
>     >> Is something like that worth writing a bug report? Or maybe it's already
>     >> known, although I can't find anything in Debbugs?
>
>     Eli> This is simply not supported, never was.  The environment variables
>     Eli> are not per-terminal, so their effect is global, and the way we
>     Eli> process them (and have no other way) is that the environment variables
>     Eli> override what terminfo tells us.
>
> 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.
>
> Robert

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.

Anyway - not so important. Just saying :-).