GNU bug report logs -
#40831
28.0.50; Remote Emacsclient with --create-frame doesn't seem to work correctly
Previous Next
Full log
View this message in rfc822 format
> Am 28.01.2021 um 10:43 schrieb Robert Pluim <rpluim <at> gmail.com>:
>
>>>>>> On Thu, 28 Jan 2021 09:42:57 +0100, Philipp Stephani <p.stephani2 <at> gmail.com> said:
>
> Philipp> Am Do., 28. Jan. 2021 um 09:21 Uhr schrieb Lars Ingebrigtsen <larsi <at> gnus.org>:
>>>
>>> Robert Pluim <rpluim <at> gmail.com> writes:
>>>
>>>> Where's the X connection that emacs would use to create the graphical
>>>> frame? Itʼs the emacs server socket thatʼs been forwarded.
>>>
>>> Yes, but the Emacs daemon and the display were both on machine 1, so
>>> the display wouldn't need to be forwarded?
>>>
>
> Yes, I was confused.
>
> Philipp> Correct, there's no X forwarding in the loop here.
>
> 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.
Thanks!
>
> 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.
Indeed, but probably also one worth reporting.
>
> BTW, have you tried doing this with tcp sockets rather than ssh
> forwarded ones?
>
Not really (AFAIK there’s no way to secure them).
This bug report was last modified 4 years and 138 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.