bug#62528: 28.2; Emacsclient doesn't use COLORTERM

[Robert Pluim <rpluim@gmail.com>]

>>>>> On Thu, 30 Mar 2023 12:34:39 +0300, Eli Zaretskii <eliz@gnu.org> said:

    >> From: Robert Pluim <rpluim@gmail.com>
    >> Cc: Vojtěch Balák <vojtech@balak.me>,
    >> 62528@debbugs.gnu.org
    >> Date: Thu, 30 Mar 2023 10:59:32 +0200
    >> 
    >> >>>>> On Thu, 30 Mar 2023 09:49:56 +0200, Vojtěch Balák <vojtech@balak.me> said:
    >> 
    >> >> COLORTERM should be in the environment of emacs when it starts, not in
    >> >> the environment of emacsclient.
    >> 
    >> Thatʼs because we look it up using `getenv' in init_tty. If we used
    >> `egetenv' instead, then we could honour the value of "COLORTERM" sent
    >> by emacsclient.

    Eli> But egetenv would be wrong here, because it looks in
    Eli> process-environment.

Well yes, thatʼs the whole point

    Eli> This is _exactly_ the issue here: emacsclient puts the environment of
    Eli> the parent shell into process-environment, so that it could be
    Eli> inherited by sub-processes, but Emacs itself should _not_ be sensitive
    Eli> to the environment it prepares for sub-processes.

Normally Iʼd agree with you, but this a grey area: weʼre creating a
new frame, so having its characteristics depend on information sent by
emacsclient makes sense, especially since server.el already goes to
the trouble of ensuring that emacsclientʼs value of COLORTERM is
inherited.

Would you accept a compromise where we check `getenv', and if the
value is empty, check `egetenv'?

Robert
--