all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* Multi-tty
@ 2024-11-07  9:53 Gerd Möllmann
  2024-11-07 10:58 ` Multi-tty Eli Zaretskii
  0 siblings, 1 reply; 27+ messages in thread
From: Gerd Möllmann @ 2024-11-07  9:53 UTC (permalink / raw)
  To: 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.)

Is something like that worth writing a bug report? Or maybe it's already
known, although I can't find anything in Debbugs?



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-07  9:53 Multi-tty Gerd Möllmann
@ 2024-11-07 10:58 ` Eli Zaretskii
  2024-11-07 11:15   ` Multi-tty Robert Pluim
  0 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2024-11-07 10:58 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: emacs-devel

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-07 10:58 ` Multi-tty Eli Zaretskii
@ 2024-11-07 11:15   ` Robert Pluim
  2024-11-07 11:38     ` Multi-tty Gerd Möllmann
                       ` (2 more replies)
  0 siblings, 3 replies; 27+ messages in thread
From: Robert Pluim @ 2024-11-07 11:15 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Gerd Möllmann, emacs-devel

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-07 11:15   ` Multi-tty Robert Pluim
@ 2024-11-07 11:38     ` Gerd Möllmann
  2024-11-07 11:47     ` Multi-tty Eli Zaretskii
  2024-11-08  8:18     ` Multi-tty Gerd Möllmann
  2 siblings, 0 replies; 27+ messages in thread
From: Gerd Möllmann @ 2024-11-07 11:38 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eli Zaretskii, emacs-devel

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-07 11:15   ` Multi-tty Robert Pluim
  2024-11-07 11:38     ` Multi-tty Gerd Möllmann
@ 2024-11-07 11:47     ` Eli Zaretskii
  2024-11-08  8:18     ` Multi-tty Gerd Möllmann
  2 siblings, 0 replies; 27+ messages in thread
From: Eli Zaretskii @ 2024-11-07 11:47 UTC (permalink / raw)
  To: Robert Pluim; +Cc: gerd.moellmann, emacs-devel

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-07 11:15   ` Multi-tty Robert Pluim
  2024-11-07 11:38     ` Multi-tty Gerd Möllmann
  2024-11-07 11:47     ` Multi-tty Eli Zaretskii
@ 2024-11-08  8:18     ` Gerd Möllmann
  2024-11-08  8:28       ` Multi-tty Gerd Möllmann
  2024-11-08  8:50       ` Multi-tty Eli Zaretskii
  2 siblings, 2 replies; 27+ messages in thread
From: Gerd Möllmann @ 2024-11-08  8:18 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eli Zaretskii, emacs-devel

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.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08  8:18     ` Multi-tty Gerd Möllmann
@ 2024-11-08  8:28       ` Gerd Möllmann
  2024-11-08  8:50       ` Multi-tty Eli Zaretskii
  1 sibling, 0 replies; 27+ messages in thread
From: Gerd Möllmann @ 2024-11-08  8:28 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eli Zaretskii, emacs-devel

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

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

bug#74252



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08  8:18     ` Multi-tty Gerd Möllmann
  2024-11-08  8:28       ` Multi-tty Gerd Möllmann
@ 2024-11-08  8:50       ` Eli Zaretskii
  2024-11-08  9:16         ` Multi-tty Gerd Möllmann
  1 sibling, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2024-11-08  8:50 UTC (permalink / raw)
  To: Gerd Möllmann, Stefan Monnier; +Cc: rpluim, emacs-devel

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08  8:50       ` Multi-tty Eli Zaretskii
@ 2024-11-08  9:16         ` Gerd Möllmann
  2024-11-08  9:42           ` Multi-tty Gerd Möllmann
  2024-11-08 11:41           ` Multi-tty Eli Zaretskii
  0 siblings, 2 replies; 27+ messages in thread
From: Gerd Möllmann @ 2024-11-08  9:16 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Stefan Monnier, rpluim, emacs-devel

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.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08  9:16         ` Multi-tty Gerd Möllmann
@ 2024-11-08  9:42           ` Gerd Möllmann
  2024-11-08 10:17             ` Multi-tty Robert Pluim
  2024-11-08 11:43             ` Multi-tty Eli Zaretskii
  2024-11-08 11:41           ` Multi-tty Eli Zaretskii
  1 sibling, 2 replies; 27+ messages in thread
From: Gerd Möllmann @ 2024-11-08  9:42 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Stefan Monnier, rpluim, emacs-devel

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.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08  9:42           ` Multi-tty Gerd Möllmann
@ 2024-11-08 10:17             ` Robert Pluim
  2024-11-08 11:09               ` Multi-tty Gerd Möllmann
  2024-11-08 11:43             ` Multi-tty Eli Zaretskii
  1 sibling, 1 reply; 27+ messages in thread
From: Robert Pluim @ 2024-11-08 10:17 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Eli Zaretskii, Stefan Monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 10:17             ` Multi-tty Robert Pluim
@ 2024-11-08 11:09               ` Gerd Möllmann
  2024-11-08 11:49                 ` Multi-tty Eli Zaretskii
  0 siblings, 1 reply; 27+ messages in thread
From: Gerd Möllmann @ 2024-11-08 11:09 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eli Zaretskii, Stefan Monnier, emacs-devel

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.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08  9:16         ` Multi-tty Gerd Möllmann
  2024-11-08  9:42           ` Multi-tty Gerd Möllmann
@ 2024-11-08 11:41           ` Eli Zaretskii
  2024-11-08 11:49             ` Multi-tty Gerd Möllmann
  2024-11-08 13:55             ` Multi-tty Stefan Monnier
  1 sibling, 2 replies; 27+ messages in thread
From: Eli Zaretskii @ 2024-11-08 11:41 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: monnier, rpluim, emacs-devel

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08  9:42           ` Multi-tty Gerd Möllmann
  2024-11-08 10:17             ` Multi-tty Robert Pluim
@ 2024-11-08 11:43             ` Eli Zaretskii
  1 sibling, 0 replies; 27+ messages in thread
From: Eli Zaretskii @ 2024-11-08 11:43 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: monnier, rpluim, emacs-devel

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 11:41           ` Multi-tty Eli Zaretskii
@ 2024-11-08 11:49             ` Gerd Möllmann
  2024-11-08 12:03               ` Multi-tty Eli Zaretskii
                                 ` (2 more replies)
  2024-11-08 13:55             ` Multi-tty Stefan Monnier
  1 sibling, 3 replies; 27+ messages in thread
From: Gerd Möllmann @ 2024-11-08 11:49 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: monnier, rpluim, emacs-devel

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.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 11:09               ` Multi-tty Gerd Möllmann
@ 2024-11-08 11:49                 ` Eli Zaretskii
  0 siblings, 0 replies; 27+ messages in thread
From: Eli Zaretskii @ 2024-11-08 11:49 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: rpluim, monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 11:49             ` Multi-tty Gerd Möllmann
@ 2024-11-08 12:03               ` Eli Zaretskii
  2024-11-08 12:25                 ` Multi-tty Gerd Möllmann
  2024-11-08 12:11               ` Multi-tty Robert Pluim
  2024-11-08 13:53               ` Multi-tty Stefan Monnier
  2 siblings, 1 reply; 27+ messages in thread
From: Eli Zaretskii @ 2024-11-08 12:03 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: monnier, rpluim, emacs-devel

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 11:49             ` Multi-tty Gerd Möllmann
  2024-11-08 12:03               ` Multi-tty Eli Zaretskii
@ 2024-11-08 12:11               ` Robert Pluim
  2024-11-08 12:29                 ` Multi-tty Gerd Möllmann
  2024-11-08 13:53               ` Multi-tty Stefan Monnier
  2 siblings, 1 reply; 27+ messages in thread
From: Robert Pluim @ 2024-11-08 12:11 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Eli Zaretskii, monnier, emacs-devel

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 12:03               ` Multi-tty Eli Zaretskii
@ 2024-11-08 12:25                 ` Gerd Möllmann
  0 siblings, 0 replies; 27+ messages in thread
From: Gerd Möllmann @ 2024-11-08 12:25 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: monnier, rpluim, emacs-devel

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.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 12:11               ` Multi-tty Robert Pluim
@ 2024-11-08 12:29                 ` Gerd Möllmann
  0 siblings, 0 replies; 27+ messages in thread
From: Gerd Möllmann @ 2024-11-08 12:29 UTC (permalink / raw)
  To: Robert Pluim; +Cc: Eli Zaretskii, monnier, emacs-devel

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.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 11:49             ` Multi-tty Gerd Möllmann
  2024-11-08 12:03               ` Multi-tty Eli Zaretskii
  2024-11-08 12:11               ` Multi-tty Robert Pluim
@ 2024-11-08 13:53               ` Stefan Monnier
  2024-11-08 13:55                 ` Multi-tty Eli Zaretskii
  2024-11-08 14:05                 ` Multi-tty Gerd Möllmann
  2 siblings, 2 replies; 27+ messages in thread
From: Stefan Monnier @ 2024-11-08 13:53 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Eli Zaretskii, rpluim, emacs-devel

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




^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 11:41           ` Multi-tty Eli Zaretskii
  2024-11-08 11:49             ` Multi-tty Gerd Möllmann
@ 2024-11-08 13:55             ` Stefan Monnier
  2024-11-08 14:24               ` Multi-tty Robert Pluim
  1 sibling, 1 reply; 27+ messages in thread
From: Stefan Monnier @ 2024-11-08 13:55 UTC (permalink / raw)
  To: Eli Zaretskii; +Cc: Gerd Möllmann, rpluim, emacs-devel

> 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




^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 13:53               ` Multi-tty Stefan Monnier
@ 2024-11-08 13:55                 ` Eli Zaretskii
  2024-11-08 14:05                 ` Multi-tty Gerd Möllmann
  1 sibling, 0 replies; 27+ messages in thread
From: Eli Zaretskii @ 2024-11-08 13:55 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: gerd.moellmann, rpluim, emacs-devel

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 13:53               ` Multi-tty Stefan Monnier
  2024-11-08 13:55                 ` Multi-tty Eli Zaretskii
@ 2024-11-08 14:05                 ` Gerd Möllmann
  2024-11-08 14:11                   ` Multi-tty Gerd Möllmann
  1 sibling, 1 reply; 27+ messages in thread
From: Gerd Möllmann @ 2024-11-08 14:05 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, rpluim, emacs-devel

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?




^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 14:05                 ` Multi-tty Gerd Möllmann
@ 2024-11-08 14:11                   ` Gerd Möllmann
  2024-11-08 15:42                     ` Multi-tty Yuri Khan
  0 siblings, 1 reply; 27+ messages in thread
From: Gerd Möllmann @ 2024-11-08 14:11 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, rpluim, emacs-devel

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.



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 13:55             ` Multi-tty Stefan Monnier
@ 2024-11-08 14:24               ` Robert Pluim
  0 siblings, 0 replies; 27+ messages in thread
From: Robert Pluim @ 2024-11-08 14:24 UTC (permalink / raw)
  To: Stefan Monnier; +Cc: Eli Zaretskii, Gerd Möllmann, emacs-devel

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



^ permalink raw reply	[flat|nested] 27+ messages in thread

* Re: Multi-tty
  2024-11-08 14:11                   ` Multi-tty Gerd Möllmann
@ 2024-11-08 15:42                     ` Yuri Khan
  0 siblings, 0 replies; 27+ messages in thread
From: Yuri Khan @ 2024-11-08 15:42 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: Stefan Monnier, Eli Zaretskii, rpluim, emacs-devel

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.



^ permalink raw reply	[flat|nested] 27+ messages in thread

end of thread, other threads:[~2024-11-08 15:42 UTC | newest]

Thread overview: 27+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-11-07  9:53 Multi-tty Gerd Möllmann
2024-11-07 10:58 ` Multi-tty Eli Zaretskii
2024-11-07 11:15   ` Multi-tty Robert Pluim
2024-11-07 11:38     ` Multi-tty Gerd Möllmann
2024-11-07 11:47     ` Multi-tty Eli Zaretskii
2024-11-08  8:18     ` Multi-tty Gerd Möllmann
2024-11-08  8:28       ` Multi-tty Gerd Möllmann
2024-11-08  8:50       ` Multi-tty Eli Zaretskii
2024-11-08  9:16         ` Multi-tty Gerd Möllmann
2024-11-08  9:42           ` Multi-tty Gerd Möllmann
2024-11-08 10:17             ` Multi-tty Robert Pluim
2024-11-08 11:09               ` Multi-tty Gerd Möllmann
2024-11-08 11:49                 ` Multi-tty Eli Zaretskii
2024-11-08 11:43             ` Multi-tty Eli Zaretskii
2024-11-08 11:41           ` Multi-tty Eli Zaretskii
2024-11-08 11:49             ` Multi-tty Gerd Möllmann
2024-11-08 12:03               ` Multi-tty Eli Zaretskii
2024-11-08 12:25                 ` Multi-tty Gerd Möllmann
2024-11-08 12:11               ` Multi-tty Robert Pluim
2024-11-08 12:29                 ` Multi-tty Gerd Möllmann
2024-11-08 13:53               ` Multi-tty Stefan Monnier
2024-11-08 13:55                 ` Multi-tty Eli Zaretskii
2024-11-08 14:05                 ` Multi-tty Gerd Möllmann
2024-11-08 14:11                   ` Multi-tty Gerd Möllmann
2024-11-08 15:42                     ` Multi-tty Yuri Khan
2024-11-08 13:55             ` Multi-tty Stefan Monnier
2024-11-08 14:24               ` Multi-tty Robert Pluim

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.