Is it possible to run gnus
or other things that tend to frequently block in a separate emacs instance and "forward the buffers" to the main emacs instance. I guess more generally I am wondering what kind of communication between emacs instances is possible.

- 877
- 5
- 19
2 Answers
Make sure that each Emacs instance runs a daemon with a unique name. Set the variable server-start
to choose the server name, for example
emacs --daemon & # Normal instance with the default server name ("server")
emacs --daemon=gnus & # Instance for GNUS only
From one instance, you can execute code in another instance with the function server-eval-at
. The value of the expression is returned to the local instance. It needs to be a value that can be read back: integers, strings, lists and other “transparent” data structures are ok, but you can transfer buffers, frames, etc. this way.
You can use this facility to tell another instance to open a frame, to list the buffer names in another instance, etc. Note that if the other instance is busy, your code will block until it replies to the daemon.
(server-eval-at "gnus" `(frame-parameter
(make-frame-on-display ,(frame-parameter (selected-frame) 'display))
window-id))
There isn't much code out there that uses this facility: most Emacs users run a single instance. So whatever you want to do, you'd probably have to do some coding work.

- 22,318
- 4
- 56
- 92
-
You can simply say
emacs --daemon=gnus
instead ofemacs --daemon --eval '(setq server-name "gnus")'
– phils Oct 04 '15 at 14:18
Emacsclient
Use instead of Emacs the Emacsclient. First you have to do a (server-start)
in your Emacs(en) and then run the client in its own frame with emacsclient -c test.mac
.
You might also distinguish different server files with the options -f ServerFile
(on Windows) or server names -s ServerName
. Please have a look at http://www.gnu.org/software/emacs/manual/html_node/emacs/emacsclient-Options.html. To that end you have to set different server names for the different Emacsen: (setq server-name "Server1")
, etc.

- 1,906
- 14
- 25
-
-
I'm afraid I don't understand fully your use cases. Could you give us examples please. – Dieter.Wilhelm Sep 04 '15 at 05:34
-
1mail-reading programs like gnus or wanderlust lock the ui while updating. I don't really need these programs to interact with the rest of emacs most of the time, but would like the buffers to be managed in a single context so I don't need to switch back and forth between the email emacs and the everything else emacs. I know that certain packages like helm use a separate emacs instance to avoid blocking, and was wondering if there's a way to display the buffers from another emacs instance instead of rewriting part of an existing emacs client to be less synchronous. – Greg Nisbet Sep 04 '15 at 05:49
-
@GregoryNisbet: I see, I've updated my answer to include your answer about multiple daemons or Emacs server instances, hope it help... – Dieter.Wilhelm Sep 04 '15 at 08:33
-
2Wouldn't it be same as running different instances of emacs, since at a time an instance of emacsclient would be able to access the buffers of only one emacs sever? – Iqbal Ansari Sep 04 '15 at 08:53
frame-bufs
https://github.com/alpaker/Frame-Bufs or a variety of other organizational libraries (e.g., projects, etc.). In a nutshell, there are many ways to effectively organize an enormous volume of active buffers within one Emacs instance. – lawlist Sep 02 '15 at 20:46el-screen
for buffer organization, but a project-oriented approach might make more sense. I'm envisioning more of a master emacs and a few headless worker emacses that do blocking things likegnus
. Simplest possible solution the emacses communicate over sockets or the master emacs spawns an ephemeral worker and all communication is done over stdin and stdout, but then I would need to go to a lot of trouble to serialize and deserialize emacs-specific objects (that is the hard work I am trying to avoid). – Greg Nisbet Sep 02 '15 at 21:01