Independent differently-configured instances running concurrently

Independent differently-configured instances running concurrently

[Hans BKK]

I'm investigating how to run completely separate instances of emacs concurrently.

For example,

 * highly customized but relatively stable "production" setup used for exploring source-code, docs, creating my own self-doc-set

 * basically unmodified "base" setup for learning vanilla and comparison purposes

 * scratch-experimental setup for testing packages, comparing their mods to vanilla, etc


It seems many people to do this with something like:

emacs -q -title custom -l "~/path/to/custom/init.el" \
      --eval "(run-hooks 'after-init-hook)"

but from a bit of research, it seems there are two disadvantages to this approach. 1 the "-q" option disables saving normal customizations and 2 non-standard eval ordering compared to running via the normal "~/.emacs.d/init.el" process.

So I'm looking for feedback on an alternative approach that would give me a stock-standard setup for each instance. So far, it seems to me that launching via a script that sets  a separate $HOME for each instance could work, e.g.

#!/bin/bash
HOME=$HOME/emacs/homes/vanilla
export PATH="~/.cask/bin:$PATH"
/bin/bash
# emacs

Many of these instances are being tracked via git, hence the preference for opening a prompt from which I can launch emacs rather than going straight in.

Note I'm a bit of a *nix noob, so feedback on the bash scripting side would be most welcome, in addition to anything emacs-specific.

So do you think this will work? Is there any potential problem of the different instances "stepping" on each other, either in RAM or perhaps writing back to global init configs?

Any other comments welcome, expect perhaps those along the lines of "your learning process is too complicated" 8-)

Re: Independent differently-configured instances running concurrently

[David Hume]

Hans BKK <hansbkk@gmail.com> writes:

>
> Any other comments welcome, expect perhaps those along the lines of "your learning process is too complicated" 8-)

At the moment I am running various instances but I just run them as
different users. For example using gnus to send mail, I am not sure how
I would have different smtp servers, without them getting mixed up, so
to play it safe I set up different linux users.

Re: Independent differently-configured instances running concurrently

[W. Greenhouse]

Hans,

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

> Any other comments welcome, expect perhaps those along the lines of
> "your learning process is too complicated" 8-)

1. If you are interested in reading in-depth about Emacs initialization,
   see (info "(elisp) Startup Summary"). This will help answer where the
   user initfile and other user config elements fit in to the session
   startup.

2. I am a fan of the Emacs daemon. Multiple daemons can be initialized
   by giving them distinct socket filenames, similar to named screen or
   tmux sessions. Each daemon can persist in the background and have its
   own set of emacsclient frames, possibly on different terminals or X
   servers.

   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 with "emacs
   --daemon=test", which enables emacsclients to be connected to the new
   instance with "emacsclient -c -s test". You can read about
   emacsclient/daemon at (info "(emacs) Emacs Server").

   If you consistently wanted to have multiple sessions with the added
   flexibility of the daemon, one option might be to have a function run
   from `after-init-hook' (run just after the daemon is up and running)
   and detect which value of `server-name' was set during
   initialization.

   For example:

--8<---------------cut here---------------start------------->8---
(defun server-specific-init ()
  "Conditionally load a secondary initfile by Emacs daemon name."
  (if (server-running-p)
      (load-file (concat user-emacs-directory "init-" server-name))))

(add-hook 'after-init-hook 'server-specific-init)
--8<---------------cut here---------------end--------------->8---

   With this you could have an init-personal.el, init-work.el,
   init-testing.el, etc. and boot into those environments by starting a
   daemon with that name. Setting ALTERNATE_EDITOR to "" in your shell
   environment it becomes even more convenient, because then you can
   start the daemon implicitly by launching an emacsclient with its
   name: "emacsclient -c -s personal", etc.

   Nonetheless I've never found such a setup easy to come to terms with,
   because one of the reasons I stick with Emacs is that I love to have
   my whole session accessible.

3. Most importantly, use Emacs. This is the best way to learn. :) Start
   with a particular task and build from there; by learning the elisp
   and commands that help with this task, you will gain much familiarity
   with the runtime in general. In the end it's all pretty
   interconnected.

David,

David Hume <David.Hume-hcDgGtZH8xNBDgjK7y7TUQ@public.gmane.org> writes:
   
> At the moment I am running various instances but I just run them as
> different users. For example using gnus to send mail, I am not sure how
> I would have different smtp servers, without them getting mixed up, so
> to play it safe I set up different linux users.

Gnus supports multiple SMTP accounts through the X-Message-SMTP-Method
header, or alternatively by using an SMTP client binary that picks a
mail host based on the From: header, like msmtp. Just as a small
aside. :)

--
Best,
WGG

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

Re: Independent differently-configured instances running concurrently

[Javier]

> Note I'm a bit of a *nix noob, so feedback on the bash scripting
> side would be most welcome, in addition to anything emacs-specific.

I would define bash functions in ~/.bashrc instead of using several
scripts, just to keep all configs inside a single file.

#include in ~/.bashrc
emacs-vanilla()
{
export HOME=$HOME/emacs/homes/vanilla
export PATH="~/.cask/bin:$PATH"
/usr/bin/emacs -title vanilla
}

emacs-...()
{
...
}

> the different instances "stepping" on each other, either in RAM or
> perhaps writing back to global init configs?

That shouldn't be a problem unless you want to use emacsclient/emacs --daemon

> Any other comments welcome

For other environment variables you can check M-x Info-goto-node 
(emacs) General Variables

Re: Independent differently-configured instances running concurrently

[Michael Heerdegen]

Hans BKK <hansbkk@gmail.com> writes:

> I'm investigating how to run completely separate instances of emacs
> concurrently.

> #!/bin/bash
> HOME=$HOME/emacs/homes/vanilla
> export PATH="~/.cask/bin:$PATH"
> /bin/bash
> # emacs

I would prefer using different Unix users, too.

In general, however, I think your approach would work, but I'm not
sure.  (BTW, should not HOME be the variable to be exported?  Why do you
run bash recursively?)

Re: Independent differently-configured instances running concurrently

[Hans BKK]

On Monday, April 28, 2014 12:54:04 PM UTC-4, Michael Heerdegen wrote:
> should not HOME be the variable to be exported?

Apparently 'export' is for sub-shells, but apparently not needed, seems to be inherited anyway.

>  Why do you run bash recursively?)

If you mean, why open to the shell rather than straight into emacs, as I said I'm tracking my config changes with git, may want to check status, pull/commit/push there before and/or after a given session.

Re: Independent differently-configured instances running concurrently

[Michael Heerdegen]

Hans BKK <hansbkk@gmail.com> writes:

> >  Why do you run bash recursively?)
>
> If you mean, why open to the shell rather than straight into emacs, as
> I said I'm tracking my config changes with git, may want to check
> status, pull/commit/push there before and/or after a given session.

No, I don't understand what you had sent:

#!/bin/bash
HOME=$HOME/emacs/homes/vanilla
export PATH="~/.cask/bin:$PATH"
/bin/bash
# emacs

What's the purpose of the second /bin/bash occurrence?  My impression is
that this script is just not your final version (with "emacs" commented
out ...)?


Michael.

Re: Independent differently-configured instances running concurrently

[Robert Thorpe]

Hans BKK <hansbkk@gmail.com> writes:

> I'm investigating how to run completely separate instances of emacs concurrently.
>
> For example,
>
>  * highly customized but relatively stable "production" setup used for exploring source-code, docs, creating my own self-doc-set
>
>  * basically unmodified "base" setup for learning vanilla and comparison purposes
>
>  * scratch-experimental setup for testing packages, comparing their mods to vanilla, etc

The way you suggest should work.  Using multiple accounts should work
too.

Another way is to use different computers.  In the past I've worked at
companies that have servers running on various types of Unix.  Often I'd
setup Emacs on my corporate MS Windows PC.  I used it on the Unix
machines too via ssh or telnet.  On the Windows machine I put all my
customizations, but I didn't customize on the Unix machines.  I did that
out of laziness, but it was useful because it got me accustomed to how
default Emacs worked and made me realize which customizations were
really useful.

All approaches make it tricky to use emacsclient, but you can learn that
later.  Emacs server/client is very useful and definitely worth setting up.

And I still think your learning process is too complicated :)

BR,
Robert Thorpe

Re: Independent differently-configured instances running concurrently

[Hans BKK]

On Monday, April 28, 2014 8:10:27 PM UTC-4, Michael Heerdegen wrote:

#!/bin/bash 
HOME=$HOME/emacs/homes/vanilla 
export PATH="~/.cask/bin:$PATH" 
/bin/bash 
# emacs 

What's the purpose of the second /bin/bash occurrence?  My impression is 
that this script is just not your final version (with "emacs" commented 
out ...)? 

I'm not sure how I can be more clear, the fact that each .emacs.dir is a tracking remote from my central repository, in case I want/need to run git commands before and/or after I run emacs. Saves maintaining a dual set of scripts for every instance - when I've climbed the linux learning curve a bit I'll check out that suggestion wrt the rc file.

But so far see no need for creating new users. . .


@Robert - well buying separate hardware for just this purpose wouldn't simplify things 8-)

Re: Independent differently-configured instances running concurrently

[Hans BKK]

@W. Greenhouse

Thanks for the details about the daemon; is there any benefit beyond reducing startup time? 

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?

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.

> Most importantly, use Emacs. This is the best way to learn. :)

Thanks, will do - once I've settled on keybindings that suit me. . .

Re: Independent differently-configured instances running concurrently

[W. Greenhouse]

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.