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

Previous Next

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

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

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; multi-tty;: init_tty using getenv for COLORTERM
Date: Fri, 08 Nov 2024 09:23:59 +0100

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.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: 74252 <at> debbugs.gnu.org
Subject: Re: bug#74252: 31.0.50; multi-tty;: init_tty using getenv for
 COLORTERM
Date: Fri, 08 Nov 2024 11:22:18 +0100

[Message part 1 (text/plain, inline)]

Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:

The following patch works perfectly for me (including daemon mode).

[0001-multi-tty-fix-wrong-COLORTERM-bug-74252.patch (text/x-patch, attachment)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Gerd Möllmann <gerd.moellmann <at> gmail.com>
Cc: 74252 <at> debbugs.gnu.org
Subject: Re: bug#74252: 31.0.50; multi-tty;
 : init_tty using getenv for COLORTERM
Date: Fri, 08 Nov 2024 13:47:15 +0200

> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
> Date: Fri, 08 Nov 2024 11:22:18 +0100
> 
> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
> 
> The following patch works perfectly for me (including daemon mode).

Thanks, but I think this is wrong.  process-environment is not
supposed to affect how Emacs works, it's supposed to affect only the
sub-processes started by Emacs.

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

From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 74252 <at> debbugs.gnu.org
Subject: Re: bug#74252: 31.0.50; multi-tty;: init_tty using getenv for
 COLORTERM
Date: Fri, 08 Nov 2024 13:00:35 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann <at> gmail.com>
>> Date: Fri, 08 Nov 2024 11:22:18 +0100
>> 
>> Gerd Möllmann <gerd.moellmann <at> gmail.com> writes:
>> 
>> The following patch works perfectly for me (including daemon mode).
>
> Thanks, but I think this is wrong.  process-environment is not
> supposed to affect how Emacs works, it's supposed to affect only the
> sub-processes started by Emacs.

I'll close this then (and used it in may Emacs :-)).

Previous Next

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