Multi-tty

Multi-tty

[Gerd Möllmann]

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?

Re: Multi-tty

[Eli Zaretskii]

> 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?

This is simply not supported, never was.  The environment variables
are not per-terminal, so their effect is global, and the way we
process them (and have no other way) is that the environment variables
override what terminfo tells us.

We support these environment variables only as poor-man's terminfo,
for when terminfo doesn't tell us the whole truth, or the user "wants
more".  So what you should do is not set any such environment
variables at all, and let Emacs deduce the terminal capabilities from
the name of the terminal.

Re: Multi-tty

[Robert Pluim]

>>>>> 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
-- 

Re: Multi-tty

[Gerd Möllmann]

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 :-).

Re: Multi-tty

[Eli Zaretskii]

> From: Robert Pluim <rpluim@gmail.com>
> Cc: Gerd Möllmann <gerd.moellmann@gmail.com>,
>   emacs-devel@gnu.org
> Date: Thu, 07 Nov 2024 12:15:28 +0100
> 
> >>>>> 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.

I wasn't talking about TERM, I was talking about COLORTERM and its
ilk.  TERM affects the terminfo library, COLORTERM overrides that.

Re: Multi-tty

[Gerd Möllmann]

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.

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.

I think I'll create a bug for that.

Re: Multi-tty

[Gerd Möllmann]

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

> I think I'll create a bug for that.

bug#74252

Re: Multi-tty

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> Date: Fri, 08 Nov 2024 09:18:05 +0100
> 
> >     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.
> 
> 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.

Yes, exactly.  But TERM is special in this sense.

> 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.

I'm not sure this is easy.  The general problem of environment
variables being terminal-specific (_not_ frame-specific!) was
discussed at length around the introduction of multi-tty into Emacs,
but AFAIR the decision was eventually to leave that unsolved, due to
non-trivial difficulties whose details I no longer recall.  You may
wish looking up those discussions, around 2003 to 2007 (look for
messages posted by Károly Lőrentey, who implemented multi-tty in
Emacs).  Or maybe Stefan remembers those discussions better.

Re: Multi-tty

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>> Date: Fri, 08 Nov 2024 09:18:05 +0100
>> 
>> >     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.
>> 
>> 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.
>
> Yes, exactly.  But TERM is special in this sense.

Right.

>> 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.
>
> I'm not sure this is easy.  The general problem of environment
> variables being terminal-specific (_not_ frame-specific!) was
> discussed at length around the introduction of multi-tty into Emacs,
> but AFAIR the decision was eventually to leave that unsolved, due to
> non-trivial difficulties whose details I no longer recall.  You may
> wish looking up those discussions, around 2003 to 2007 (look for
> messages posted by Károly Lőrentey, who implemented multi-tty in
> Emacs).  Or maybe Stefan remembers those discussions better.

I wouldn't try to "fix" the general handling of environment variables,
if that's even possible, which I kind of doubt as you do, I think. I'd
just replace the getenv("COLORTERM") with some lookup of COLORTERM in
what emacsclient sent to the server.

Re: Multi-tty

[Gerd Möllmann]

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

> Eli Zaretskii <eliz@gnu.org> writes:
>
>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
>>> Date: Fri, 08 Nov 2024 09:18:05 +0100
>>> 
>>> >     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.
>>> 
>>> 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.
>>
>> Yes, exactly.  But TERM is special in this sense.
>
> Right.
>
>>> 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.
>>
>> I'm not sure this is easy.  The general problem of environment
>> variables being terminal-specific (_not_ frame-specific!) was
>> discussed at length around the introduction of multi-tty into Emacs,
>> but AFAIR the decision was eventually to leave that unsolved, due to
>> non-trivial difficulties whose details I no longer recall.  You may
>> wish looking up those discussions, around 2003 to 2007 (look for
>> messages posted by Károly Lőrentey, who implemented multi-tty in
>> Emacs).  Or maybe Stefan remembers those discussions better.
>
> I wouldn't try to "fix" the general handling of environment variables,
> if that's even possible, which I kind of doubt as you do, I think. I'd
> just replace the getenv("COLORTERM") with some lookup of COLORTERM in
> what emacsclient sent to the server.

And all that's necessary is

modified   src/term.c
@@ -4383,7 +4383,7 @@ init_tty (const char *name, const char *terminal_type, bool must_succeed)
 	   (de-facto standard introduced by tmux) or if	requested by
 	   the COLORTERM environment variable.  */
 	else if ((tigetflag ("Tc") > 0)
-		 || ((bg = getenv ("COLORTERM")) != NULL
+		 || ((bg = egetenv ("COLORTERM")) != NULL
 		     && strcasecmp (bg, "truecolor") == 0))
 	  {
 	    tty->TS_set_foreground = "\033[%?%p1%{8}%<%t3%p1%d%e38;2;%p1%{65536}%/%d;%p1%{256}%/%{255}%&%d;%p1%{255}%&%d%;m";

A one character change, isn't that funny :-).

It works because server.el puts COLORTERM in process-environment
already, in server-with-environment.

Re: Multi-tty

[Robert Pluim]

>>>>> On Fri, 08 Nov 2024 10:42:58 +0100, Gerd Möllmann <gerd.moellmann@gmail.com> said:
    Gerd> And all that's necessary is

    Gerd> modified   src/term.c
    Gerd> @@ -4383,7 +4383,7 @@ init_tty (const char *name, const char *terminal_type, bool must_succeed)
    Gerd>  	   (de-facto standard introduced by tmux) or if	requested by
    Gerd>  	   the COLORTERM environment variable.  */
    Gerd>  	else if ((tigetflag ("Tc") > 0)
    Gerd> -		 || ((bg = getenv ("COLORTERM")) != NULL
    Gerd> +		 || ((bg = egetenv ("COLORTERM")) != NULL
    Gerd>  		     && strcasecmp (bg, "truecolor") == 0))
    Gerd>  	  {
    tty-> TS_set_foreground = "\033[%?%p1%{8}%<%t3%p1%d%e38;2;%p1%{65536}%/%d;%p1%{256}%/%{255}%&%d;%p1%{255}%&%d%;m";

    Gerd> A one character change, isn't that funny :-).

    Gerd> It works because server.el puts COLORTERM in process-environment
    Gerd> already, in server-with-environment.

Eli disagreed with such a change last time it came up:
<https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62528>

Robert
-- 

Re: Multi-tty

[Gerd Möllmann]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Fri, 08 Nov 2024 10:42:58 +0100, Gerd Möllmann <gerd.moellmann@gmail.com> said:
>     Gerd> And all that's necessary is
>
>     Gerd> modified   src/term.c
>     Gerd> @@ -4383,7 +4383,7 @@ init_tty (const char *name, const char *terminal_type, bool must_succeed)
>     Gerd>  	   (de-facto standard introduced by tmux) or if	requested by
>     Gerd>  	   the COLORTERM environment variable.  */
>     Gerd>  	else if ((tigetflag ("Tc") > 0)
>     Gerd> -		 || ((bg = getenv ("COLORTERM")) != NULL
>     Gerd> +		 || ((bg = egetenv ("COLORTERM")) != NULL
>     Gerd>  		     && strcasecmp (bg, "truecolor") == 0))
>     Gerd>  	  {
>     tty-> TS_set_foreground =
> "\033[%?%p1%{8}%<%t3%p1%d%e38;2;%p1%{65536}%/%d;%p1%{256}%/%{255}%&%d;%p1%{255}%&%d%;m";
>
>     Gerd> A one character change, isn't that funny :-).
>
>     Gerd> It works because server.el puts COLORTERM in process-environment
>     Gerd> already, in server-with-environment.
>
> Eli disagreed with such a change last time it came up:
> <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62528>

Errare humanum est.

Re: Multi-tty

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  rpluim@gmail.com,
>   emacs-devel@gnu.org
> Date: Fri, 08 Nov 2024 10:16:05 +0100
> 
> I wouldn't try to "fix" the general handling of environment variables,
> if that's even possible, which I kind of doubt as you do, I think. I'd
> just replace the getenv("COLORTERM") with some lookup of COLORTERM in
> what emacsclient sent to the server.

I have another suggestion: remove the support for COLORTERM entirely,
or at least announce that it is not supported per-terminal.  It's high
time terminals that support true color have their terminfo entries
fixed and up-to-date.  We supported COLORTERM during the transition
period, as a temporary kludge, to help people who had those terminals,
but whose terminfo DB did not yet catch up, but we should slowly move
towards removing that support from Emacs.

Re: Multi-tty

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  rpluim@gmail.com,
>   emacs-devel@gnu.org
> Date: Fri, 08 Nov 2024 10:42:58 +0100
> 
> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
> 
> > Eli Zaretskii <eliz@gnu.org> writes:
> >
> >>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> >>> Cc: Eli Zaretskii <eliz@gnu.org>,  emacs-devel@gnu.org
> >>> Date: Fri, 08 Nov 2024 09:18:05 +0100
> >>> 
> >>> >     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.
> >>> 
> >>> 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.
> >>
> >> Yes, exactly.  But TERM is special in this sense.
> >
> > Right.
> >
> >>> 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.
> >>
> >> I'm not sure this is easy.  The general problem of environment
> >> variables being terminal-specific (_not_ frame-specific!) was
> >> discussed at length around the introduction of multi-tty into Emacs,
> >> but AFAIR the decision was eventually to leave that unsolved, due to
> >> non-trivial difficulties whose details I no longer recall.  You may
> >> wish looking up those discussions, around 2003 to 2007 (look for
> >> messages posted by Károly Lőrentey, who implemented multi-tty in
> >> Emacs).  Or maybe Stefan remembers those discussions better.
> >
> > I wouldn't try to "fix" the general handling of environment variables,
> > if that's even possible, which I kind of doubt as you do, I think. I'd
> > just replace the getenv("COLORTERM") with some lookup of COLORTERM in
> > what emacsclient sent to the server.
> 
> And all that's necessary is
> 
> modified   src/term.c
> @@ -4383,7 +4383,7 @@ init_tty (const char *name, const char *terminal_type, bool must_succeed)
>  	   (de-facto standard introduced by tmux) or if	requested by
>  	   the COLORTERM environment variable.  */
>  	else if ((tigetflag ("Tc") > 0)
> -		 || ((bg = getenv ("COLORTERM")) != NULL
> +		 || ((bg = egetenv ("COLORTERM")) != NULL
>  		     && strcasecmp (bg, "truecolor") == 0))
>  	  {
>  	    tty->TS_set_foreground = "\033[%?%p1%{8}%<%t3%p1%d%e38;2;%p1%{65536}%/%d;%p1%{256}%/%{255}%&%d;%p1%{255}%&%d%;m";
> 
> A one character change, isn't that funny :-).
> 
> It works because server.el puts COLORTERM in process-environment
> already, in server-with-environment.

process-environment is not supposed to affect Emacs, it's there to
affect sub-processes of Emacs.

This is exactly the crux of the problem of supporting per-terminal
environment variables.

Re: Multi-tty

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  rpluim@gmail.com,
>>   emacs-devel@gnu.org
>> Date: Fri, 08 Nov 2024 10:16:05 +0100
>> 
>> I wouldn't try to "fix" the general handling of environment variables,
>> if that's even possible, which I kind of doubt as you do, I think. I'd
>> just replace the getenv("COLORTERM") with some lookup of COLORTERM in
>> what emacsclient sent to the server.
>
> I have another suggestion: remove the support for COLORTERM entirely,
> or at least announce that it is not supported per-terminal.  It's high
> time terminals that support true color have their terminfo entries
> fixed and up-to-date.  We supported COLORTERM during the transition
> period, as a temporary kludge, to help people who had those terminals,
> but whose terminfo DB did not yet catch up, but we should slowly move
> towards removing that support from Emacs.

COLORTERM is used right now by popular programs (e.g. iTerm2) on my
system (macOS). So doing that is not an option for me.

Re: Multi-tty

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>,  Stefan Monnier
>  <monnier@iro.umontreal.ca>,  emacs-devel@gnu.org
> Date: Fri, 08 Nov 2024 12:09:36 +0100
> 
> Robert Pluim <rpluim@gmail.com> writes:
> 
> >>>>>> On Fri, 08 Nov 2024 10:42:58 +0100, Gerd Möllmann <gerd.moellmann@gmail.com> said:
> >     Gerd> And all that's necessary is
> >
> >     Gerd> modified   src/term.c
> >     Gerd> @@ -4383,7 +4383,7 @@ init_tty (const char *name, const char *terminal_type, bool must_succeed)
> >     Gerd>  	   (de-facto standard introduced by tmux) or if	requested by
> >     Gerd>  	   the COLORTERM environment variable.  */
> >     Gerd>  	else if ((tigetflag ("Tc") > 0)
> >     Gerd> -		 || ((bg = getenv ("COLORTERM")) != NULL
> >     Gerd> +		 || ((bg = egetenv ("COLORTERM")) != NULL
> >     Gerd>  		     && strcasecmp (bg, "truecolor") == 0))
> >     Gerd>  	  {
> >     tty-> TS_set_foreground =
> > "\033[%?%p1%{8}%<%t3%p1%d%e38;2;%p1%{65536}%/%d;%p1%{256}%/%{255}%&%d;%p1%{255}%&%d%;m";
> >
> >     Gerd> A one character change, isn't that funny :-).
> >
> >     Gerd> It works because server.el puts COLORTERM in process-environment
> >     Gerd> already, in server-with-environment.
> >
> > Eli disagreed with such a change last time it came up:
> > <https://debbugs.gnu.org/cgi/bugreport.cgi?bug=62528>
> 
> Errare humanum est.

Quidem.

Of course, we disagree about who is the human here that errs.

Re: Multi-tty

[Eli Zaretskii]

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Cc: monnier@iro.umontreal.ca,  rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 08 Nov 2024 12:49:02 +0100
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > I have another suggestion: remove the support for COLORTERM entirely,
> > or at least announce that it is not supported per-terminal.  It's high
> > time terminals that support true color have their terminfo entries
> > fixed and up-to-date.  We supported COLORTERM during the transition
> > period, as a temporary kludge, to help people who had those terminals,
> > but whose terminfo DB did not yet catch up, but we should slowly move
> > towards removing that support from Emacs.
> 
> COLORTERM is used right now by popular programs (e.g. iTerm2) on my
> system (macOS). So doing that is not an option for me.

Why cannot those terminal have their terminfo entry set up with
true-color support?

Anyway, as long as all of your client frames are on iTerm2, you should
be fine.

Re: Multi-tty

[Robert Pluim]

>>>>> On Fri, 08 Nov 2024 12:49:02 +0100, Gerd Möllmann <gerd.moellmann@gmail.com> said:

    Gerd> Eli Zaretskii <eliz@gnu.org> writes:
    >>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
    >>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  rpluim@gmail.com,
    >>> emacs-devel@gnu.org
    >>> Date: Fri, 08 Nov 2024 10:16:05 +0100
    >>> 
    >>> I wouldn't try to "fix" the general handling of environment variables,
    >>> if that's even possible, which I kind of doubt as you do, I think. I'd
    >>> just replace the getenv("COLORTERM") with some lookup of COLORTERM in
    >>> what emacsclient sent to the server.
    >> 
    >> I have another suggestion: remove the support for COLORTERM entirely,
    >> or at least announce that it is not supported per-terminal.  It's high
    >> time terminals that support true color have their terminfo entries
    >> fixed and up-to-date.  We supported COLORTERM during the transition
    >> period, as a temporary kludge, to help people who had those terminals,
    >> but whose terminfo DB did not yet catch up, but we should slowly move
    >> towards removing that support from Emacs.

    Gerd> COLORTERM is used right now by popular programs (e.g. iTerm2) on my
    Gerd> system (macOS). So doing that is not an option for me.

You just need the right terminfo entry for iTerm2. See eg

<https://emacs.stackexchange.com/questions/32506/conditional-true-color-24-bit-color-support-for-iterm2-and-terminal-app-in-osx>

Robert
-- 

Re: Multi-tty

[Gerd Möllmann]

Eli Zaretskii <eliz@gnu.org> writes:

>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>> Cc: monnier@iro.umontreal.ca,  rpluim@gmail.com,  emacs-devel@gnu.org
>> Date: Fri, 08 Nov 2024 12:49:02 +0100
>> 
>> Eli Zaretskii <eliz@gnu.org> writes:
>> 
>> > I have another suggestion: remove the support for COLORTERM entirely,
>> > or at least announce that it is not supported per-terminal.  It's high
>> > time terminals that support true color have their terminfo entries
>> > fixed and up-to-date.  We supported COLORTERM during the transition
>> > period, as a temporary kludge, to help people who had those terminals,
>> > but whose terminfo DB did not yet catch up, but we should slowly move
>> > towards removing that support from Emacs.
>> 
>> COLORTERM is used right now by popular programs (e.g. iTerm2) on my
>> system (macOS). So doing that is not an option for me.
>
> Why cannot those terminal have their terminfo entry set up with
> true-color support?

I don't know, you'd have to ask them.

> Anyway, as long as all of your client frames are on iTerm2, you should
> be fine.

Unless the support is removed, of course, which I hope it's not because
it's used in the wild.

And when you want to use an Emacs daemon, you also have to know that you
have to set COLORTERM for the daemon (iTerm2 for example does that
automatically in terminal windows but can't for a daemon of course), and
of course how to do it (tip: man launchd.plist). And then, you'll have
to remember to always use the right terminal emulator with the daemon,
while things just work with what I'm using now.

Quite unfortunate that all for "normal" users, IMO.

Re: Multi-tty

[Gerd Möllmann]

Robert Pluim <rpluim@gmail.com> writes:

>>>>>> On Fri, 08 Nov 2024 12:49:02 +0100, Gerd Möllmann <gerd.moellmann@gmail.com> said:
>
>     Gerd> Eli Zaretskii <eliz@gnu.org> writes:
>     >>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>     >>> Cc: Stefan Monnier <monnier@iro.umontreal.ca>,  rpluim@gmail.com,
>     >>> emacs-devel@gnu.org
>     >>> Date: Fri, 08 Nov 2024 10:16:05 +0100
>     >>> 
>     >>> I wouldn't try to "fix" the general handling of environment variables,
>     >>> if that's even possible, which I kind of doubt as you do, I think. I'd
>     >>> just replace the getenv("COLORTERM") with some lookup of COLORTERM in
>     >>> what emacsclient sent to the server.
>     >> 
>     >> I have another suggestion: remove the support for COLORTERM entirely,
>     >> or at least announce that it is not supported per-terminal.  It's high
>     >> time terminals that support true color have their terminfo entries
>     >> fixed and up-to-date.  We supported COLORTERM during the transition
>     >> period, as a temporary kludge, to help people who had those terminals,
>     >> but whose terminfo DB did not yet catch up, but we should slowly move
>     >> towards removing that support from Emacs.
>
>     Gerd> COLORTERM is used right now by popular programs (e.g. iTerm2) on my
>     Gerd> system (macOS). So doing that is not an option for me.
>
> You just need the right terminfo entry for iTerm2. See eg
>
> <https://emacs.stackexchange.com/questions/32506/conditional-true-color-24-bit-color-support-for-iterm2-and-terminal-app-in-osx>
>

Thanks, I know how to work around that. It's just another thing that
could work OOTB, but doesn't.

Re: Multi-tty

[Stefan Monnier]

Gerd Möllmann [2024-11-08 12:49:02] wrote:
> COLORTERM is used right now by popular programs (e.g. iTerm2) on my
> system (macOS). So doing that is not an option for me.

Have you reported this as a bug over on iTerm2?
AFAIK that envvar was a kludge and shouldn't be needed any more.


        Stefan

Re: Multi-tty

[Stefan Monnier]

> I have another suggestion: remove the support for COLORTERM entirely,
> or at least announce that it is not supported per-terminal.

I'd declare it deprecated, indeed.
Maybe emit a message when it's set?


        Stefan

Re: Multi-tty

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: Eli Zaretskii <eliz@gnu.org>,  rpluim@gmail.com,  emacs-devel@gnu.org
> Date: Fri, 08 Nov 2024 08:53:12 -0500
> 
> Gerd Möllmann [2024-11-08 12:49:02] wrote:
> > COLORTERM is used right now by popular programs (e.g. iTerm2) on my
> > system (macOS). So doing that is not an option for me.
> 
> Have you reported this as a bug over on iTerm2?
> AFAIK that envvar was a kludge and shouldn't be needed any more.

Agreed.

Re: Multi-tty

[Gerd Möllmann]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> Gerd Möllmann [2024-11-08 12:49:02] wrote:
>> COLORTERM is used right now by popular programs (e.g. iTerm2) on my
>> system (macOS). So doing that is not an option for me.
>
> Have you reported this as a bug over on iTerm2?
> AFAIK that envvar was a kludge and shouldn't be needed any more.

No, I didn't; it wasn't (and now isn't) a problem for me. Maybe one of
you wants to do that?

Re: Multi-tty

[Gerd Möllmann]

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

> Stefan Monnier <monnier@iro.umontreal.ca> writes:
>
>> Gerd Möllmann [2024-11-08 12:49:02] wrote:
>>> COLORTERM is used right now by popular programs (e.g. iTerm2) on my
>>> system (macOS). So doing that is not an option for me.
>>
>> Have you reported this as a bug over on iTerm2?
>> AFAIK that envvar was a kludge and shouldn't be needed any more.
>
> No, I didn't; it wasn't (and now isn't) a problem for me. Maybe one of
> you wants to do that?

BTW, just intalled and checked Alacritty, and it looks like it does the
same. ISTR Kitty also does that, but I didn't check.

Re: Multi-tty

[Robert Pluim]

>>>>> On Fri, 08 Nov 2024 08:55:24 -0500, Stefan Monnier <monnier@iro.umontreal.ca> said:

    >> I have another suggestion: remove the support for COLORTERM entirely,
    >> or at least announce that it is not supported per-terminal.

    Stefan> I'd declare it deprecated, indeed.
    Stefan> Maybe emit a message when it's set?

You mean a *Warnings* buffer, right? Emitting messages when weʼre in
the process of initalizing a new tty frame sounds like a bad idea to
me.

Robert
-- 

Re: Multi-tty

[Yuri Khan]

On Fri, 8 Nov 2024 at 21:13, Gerd Möllmann <gerd.moellmann@gmail.com> wrote:

> BTW, just intalled and checked Alacritty, and it looks like it does the
> same. ISTR Kitty also does that, but I didn't check.

Kitty has shipped a terminfo database entry including ‘setab’ and
‘setaf’ capabilities since long ago. Also, the ncurses terminfo
database collection has included ‘kitty-*’ entries for some time.