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

From: Robert Pluim <rpluim <at> gmail.com>
To: Philipp Stephani <p.stephani2 <at> gmail.com>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, 40831 <at> debbugs.gnu.org
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 <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.

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

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.