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=gnusinstead 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-bufshttps://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-screenfor 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