I know that after calling (start-server) inside an existing Emacs session, I can use emacsclient -c (on the same computer) to create new frames that connect to this server, so that every new frame created by emacsclient has access to one and the same set of general conditions (e.g., buffers).
Most of the documentation I found focuses on “give me quick access to my local Emacs,” and so there are two things that I haven't seen about:
Can emacsclient -c access Emacs servers started by other users, or is it difficult to connect only sessions started by my own user?
Does the Emacs server support (directly or indirectly) remote connections? That is, is there a way to configure Emacs (possibly using SSH) that allows emacsclient -c calls on remote computers to access the local state of my Emacs server?
(In case you haven’t guessed yet, what I would ultimately want to do is combine the two above methods to provide rudimentary support for collaboration.)
This is a real problem, so here I work:
- The required functionality should be built into Emacs already (23.3.1, 64-bit). I can stretch Emacs extensions from standard Ubuntu repositories, but I would prefer not to. (Which, I think, confuses Rudel,).
- No new users or user spoofing. Solutions should work with the existing set of user accounts, and users should not pretend to be other users (for example, via
su or ssh ).
If it matters, the machines are on a private LAN, the OpenSSH clients and servers are installed and running, and all users can connect to their computers (their own account), but they don’t have a common file system.
So, does anyone know if the Emacs server can
- share with other users or
- provide remote access?
EDIT
As indicated in rwb's answer, it is clear that new windows that open locally by running emacsclient -c are actually created by the remote Emacs server process. That is, emacsclient simply invokes the corresponding behavior on the server. This causes some problems with incorrect display settings, since the server usually does not have access to the local desktop (see below). However, I can now connect to a remote Emacs session if I use the following sequence of commands:
In one terminal, where 1.22.333.44 is the 1.22.333.44 IP address:
ssh -t -X remotehost \ "emacs -nw --eval '(progn (setq server-host \"1.22.333.44\" server-use-tcp t) (server-start))'"
Then in another (on the same machine):
scp remotehost:.emacs.d/server/server /tmp/server-file DISPLAY=localhost:10 emacsclient -c -f /tmp/server-file
The emacsclient command forces the remote Emacs server (which it finds details in /tmp/server-file ) to open the Emacs graphical window (on the local display), which shares state with the Emacs session on the remote host.
Since the remote Emacs server was started via ssh -X , SSH gives it access to my local display through a "fake" :10 display. The DISPLAY=:10 passed to it (via emacsclient ) causes a window to open on my local desktop.
Although the above approach makes the mark "Run Emacs server on a remote computer, connect to it using emacsclient locally", it is very limited. In fact, it is not much different from the fact that the server and clients work locally as one user: the only difference is that the server is now deleted, therefore it has access to various system resources.
Unfortunately, running through ssh -X is the only way I was able to successfully open a window on another X server computer:
Setting the base DISPLAY=remote:0 no good (since Ubuntu X servers start with the -nolisten tcp option).
Connecting via SSH and then using DISPLAY=:0 also fails, but this time only due to the lack of suitable credentials. (I believe the case, anyway: the error message cryptically says No protocol specified / Can't open display .)
I think that finding a way around the second problem will probably bring me closer to a solution.
After reading the posts at http://comments.gmane.org/gmane.emacs.devel/103350 (starting at October 25, 2:50 p.m., about halfway down) m, starting to wonder if this might be one of the rare things that Emacs cannot do (i.e. impossible ;-)).
However, if anyone has a way to provide access to remote X-displays without the permission error above, I am still open to convince ....
TL; DR
As indicated in rwb's answer, my questions above about whether Emacs can provide remote access got things back. There is no real problem with providing Emacs to other users ( server-use-tcp and a suitable server-file ): rather, the problem is how to allow a process on one machine to open new windows X for other users "X displays (in particular, to start Emacs (start-server) you need to open windows for users who request it through emacsclient -c ). This answer is beyond the scope of this question.
Alternative solution
As a workaround, we use the following:
- machine0:
tmux -S /tmp/shared-tmux-socket new-session - machine1..machineN:
ssh -t machine0 tmux -S /tmp/shared-tmux-socket attach
with appropriate file permissions on /tmp/shared-tmux-socket .
Then we run Emacs text mode in the shared terminal. :-) This raises some issues related to spoofing, but at least the host can see everything the guests are doing.