bug#40831: 28.0.50; Remote Emacsclient with --create-frame doesn't seem to work correctly

[Robert Pluim]

>>>>> On Sun, 31 Jan 2021 20:43:53 +0100, Philipp <p.stephani2@gmail.com> said:

    Philipp> emacsclient -t also doesn't work right: It reuses an existing
    Philipp> graphical frame on the first machine, rather than creating a new 
TTY
    Philipp> frame, and it prints internal TRAMP status messages into the file
    Philipp> buffer.
    >> 
    Philipp> emacsclient without either --create-frame or -t works fine (but
    Philipp> doesn't create a frame).
    >> 
    >> It all works fine for me, with one important caveat: I only have one
    >> Linux machine, so Iʼm ssh'ing back to myself. Iʼll see if I can rustle
    >> up a second one in the cloud somewhere.

    Philipp> Thanks!

So I found one, and I see the same issues, although I donʼt get Tramp
status messages in the buffer, but what looks like terminal control
codes.

    >> 
    >> It fails for me when the remote machine is macOS with
    >> 
    >> *ERROR*: Could not open file: /dev/ttys005
    >> 
    >> but I think thatʼs a different bug.

    Philipp> Indeed, but probably also one worth reporting.

Because of (reasons) Iʼm not too enthusiastic about reporting and
debugging issues involving macOS.

    >> 
    >> BTW, have you tried doing this with tcp sockets rather than ssh
    >> forwarded ones?
    >> 

    Philipp> Not really (AFAIK there’s no way to secure them).

Depends what you mean by secure them. You can instruct server.el to
listen on a tcp socket on localhost, and forward that using ssh. The
server file contains an auth cookie that you'd need to copy to the
remote host.

Anyway, Iʼve just tried it, and the failures are the same. I guess
Someone™ needs to step through server.el to figure out what's going on.

Robert