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.