all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: W. Greenhouse <wgreenhouse-sGOZH3hwPm2sTnJN9+BGXg@public.gmane.org>
To: help-gnu-emacs-mXXj517/zsQ@public.gmane.org
Subject: Re: Independent differently-configured instances running concurrently
Date: Tue, 29 Apr 2014 20:24:32 +0000	[thread overview]
Message-ID: <8738gvvq7z.fsf@motoko.kusanagi> (raw)
In-Reply-To: a775b46a-5fa4-43aa-84a6-95fb0a391f46@googlegroups.com

Hans BKK <hansbkk-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> writes:

> @W. Greenhouse
>
> Thanks for the details about the daemon; is there any benefit beyond
> reducing startup time?

The daemon can be used essentially as a terminal multiplexer (like GNU
Screen/tmux), except it works across X sessions, too. So combined with
ssh (with or without X forwarding), it gives you a network-transparent,
text-oriented Emacs "desktop". It is similar to the utility one would
get as a text-tool user by using GNU Screen or tmux, thus keeping open
their mailclient, chat client, editor windows, etc., all preserved for
them and ready to use from a remote terminal; I can walk away from my
home desktop, ssh into it, and have the same emacs state waiting for me.

The daemon also allows remote evaluation of code, from one Emacs
instance to another via `server-eval-at' or from any arbitrary program
which can shell out to an Emacs daemon via emacsclient --eval.

Reducing startup time is probably the least interesting and least
important feature of the daemon. :)

> I'm sure I'll put it to use for my evolving "production" setup once
> I'm actually using emacs.
>
>> I don't normally use multiple instances, because I find it more
>> convenient to have kill ring/command history/buffers shared and
>> available from any of my emacsclients, but sometimes when testing a
>> new configuration I will start up a second daemon
>
> Well pretty much all I'm doing is testing configuration stuff ATM. Not
> sure what the benefit would be of having multiple daemons running?

The same as for multiple Emacs processes in general; it may be that for
organizational purposes (e.g. dividing home from work tasks, or giving a
separate instance to mail/IRC/whatever) you want the processes isolated
from each other, or you may want this for testing new configurations in
isolation from your main Emacs daemon process.

> I assume if I change a given config I'd need to kill that
> daemon-instance as well as any client frames to see the effects.

Not really. An important feature of Emacs as a Lisp-based environment is
being able to rewrite your environment in real time. Anything that can
be done in terms of Emacs programming and configuration (including
redefining functions in the Emacs "standard library") can be done in a
running session: in the *scratch* buffer or IELM (different variations
on REPL-like interaction), by remote evaluation on an emacs daemon, or
by evaluating parts of an elisp library as you edit it. But a second
instance can be used to hack and break things in isolation from your
real work environment. (I don't bother doing this very often because
even when I hack and break things in my main instance, Emacs is quite
conscientious about backing up my real work; between the auto-save and
backup facilities, data loss is essentially nonexistent.)

--
Best,
WGG

Reply to list only, please.
Off-list replies will be filtered and deleted.




      reply	other threads:[~2014-04-29 20:24 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-28 15:39 Independent differently-configured instances running concurrently Hans BKK
2014-04-28 15:43 ` David Hume
2014-04-29 15:23   ` W. Greenhouse
2014-04-28 16:47 ` Javier
2014-04-28 16:54 ` Michael Heerdegen
2014-04-28 23:17 ` Hans BKK
2014-04-29  0:10   ` Michael Heerdegen
2014-04-29  0:18 ` Robert Thorpe
2014-04-29  0:36 ` Hans BKK
2014-04-29 18:12 ` Hans BKK
2014-04-29 20:24   ` W. Greenhouse [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=8738gvvq7z.fsf@motoko.kusanagi \
    --to=wgreenhouse-sgozh3hwpm2stnjn9+bgxg@public.gmane.org \
    --cc=help-gnu-emacs-mXXj517/zsQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.