Re: Remote TCP server through ssh tunnel

[Stefan Monnier]

>> ":0.0" is the name you generally use for connecting to the local X11
>> display on the machine running the X program.  That's what you've got
>> on the client, and what emacsclient passes over to the emacs server
>> process.  Unfortunately since that's running on a different machine,
>> the local X display *there* -- if there even is one -- is not the one
>> on your client machine.
> What I expected was to run emacsclient as a sort of UI client
> interacting with a remote server.

emacsclient, as it is implemented currently, is an application that just
sends some commands to the Emacs server and then exits (in the most
complex case it will wait for Emacs to send a reply before exiting).

We could try to make it more complex and have emacsclient to care of
doing the display: that would make it more "robust" in the sense that it
would work in more circumstances, but that would mean designing and
implementing an ad-hoc protocol.  Tho maybe we could do it by reusing an
existing system: e.g. we could have emacsclient create something like an
lbx tunnel.  And of course we'd want to do the same for ttys.

> In any case, I suppose emacs is not ready for such a client-server
> interaction, although I don't really know if that would be hard to
> achieve.

I think that if we reuse something like lbx, it might not be too difficult.

> That's what I do, but is not comfortable for high delay network
> connections. As I said, I expected to run locally "as much as possible",
> but modify everything remotely.

If you want to do as much as possible locally, I think that Tramp is
your friend.


        Stefan