bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Robert Pluim
Subject: bug#40831: 28.0.50; Remote Emacsclient with --create-frame doesn't seem to work correctly
Date: Thu, 28 Jan 2021 10:43:49 +0100

>>>>> On Thu, 28 Jan 2021 09:42:57 +0100, Philipp Stephani 
>>>>> <p.stephani2@gmail.com> said:

    Philipp> Am Do., 28. Jan. 2021 um 09:21 Uhr schrieb Lars Ingebrigtsen 
<larsi@gnus.org>:
    >> 
    >> Robert Pluim <rpluim@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.

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.

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

Robert





reply via email to

[Prev in Thread] Current Thread [Next in Thread]