Re: Multi-tty

[Eli Zaretskii <eliz@gnu.org>]

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