Error when using a config directory other than .emacs.d

[brabalan]

I want to try spacemacs alongside my usual emacs, so I cloned the repository to ~/src/spacemacs and I'm launching it like this:

open /Applications/Emacs.app -n --args -Q --eval '(progn (setq user-emacs-directory "~/src/spacemacs/") (load-file "~/src/spacemacs/init.el"))'

The initial setup works fine until it's done compiling files. I then see this in the *Messages* buffer:

Loading /Users/schmitta/src/spacemacs/init.el (source)...done
Start checking for new version...
Open the quickhelp.
error in process sentinel: if: Cannot open load file: no such file or directory, /Users/schmitta/.emacs.d/core/core-load-paths.el
error in process sentinel: Cannot open load file: no such file or directory, /Users/schmitta/.emacs.d/core/core-load-paths.el

When toggling debug-on-error I get the following backtrace

Debugger entered--Lisp error: (file-error "Cannot open load file" "no such file or directory" "/Users/schmitta/.emacs.d/core/core-load-paths.el")
  signal(file-error ("Cannot open load file" "no such file or directory" "/Users/schmitta/.emacs.d/core/core-load-paths.el"))
  async-handle-result((lambda (result) (if result (if (or (version< result spacemacs-version) (string= result spacemacs-version) (if spacemacs-new-version (string= result spacemacs-new-version))) (message "Spacemacs is up to date.") (message "New version of Spacemacs available: %s" result) (setq spacemacs-new-version result)) (message "Unable to check for new version."))) (async-signal (file-error "Cannot open load file" "no such file or directory" "/Users/schmitta/.emacs.d/core/core-load-paths.el")) #<buffer *emacs*>)
  async-when-done(#<process emacs> "finished\n")

I guess the problem comes from here: https://github.com/syl20bnr/spacemacs/blob/master/core/core-release-management.el#L70

It seems that async-start call does not inherit the value of user-emacs-directory that I set. If I evaluate

(async-start (lambda () user-emacs-directory) (lambda (result) (message "got %s" result)))

I get got ~/.emacs.d/ in the *Messages* buffer.

A potential fix is to inject the variable in the async call, as in

(async-start `(lambda () ,(async-inject-variables "\\`user-emacs-directory\\'") user-emacs-directory) (lambda (result) (message "got %s" result)))

[justbur]

http://emacs.stackexchange.com/questions/4253/how-to-start-emacs-with-a-custom-user-emacs-directory

[brabalan]

@justbur Thank you for the suggestion. The first answer suggests changing HOME, which is a bit too much. The second answer is very similar to what I propose and has the same problem.

[d12frosted]

Several months ago, I was switching emacs configurations pretty often. What I did is just writing and using simple script like following

#!/bin/sh

case $1 in
    "own")
        emacs_path=~/.emacs.d.own
          ;;

    "spacemacs")
          emacs_path=~/.emacs.d.spacemacs
          ;;

    "purcell")
          emacs_path=~/.emacs.d.purcell
          ;;

    *)
          echo "unknown type"
          exit 1
          ;;
esac

echo "Switching from '$(readlink ~/.emacs.d)'
            to '$emacs_path'"
rm -rf ~/.emacs.d
ln -s $emacs_path ~/.emacs.d

So actually, my ~/.emacs.d is just a symbolic link to configuration I am using right now. What's bad about it - you can have only one active configuration at the same time. But I hadn't any problems with that.

P. S. I know it doesn't really solve your initial problem, but depending on reasons you have two use different configurations it might help.

Updated

But yeah, changing value of HOME is canon shot 😄 Don't understand why it was accepted. It might lead to some very strange problems.

[TheBB]

Why is changing HOME so bad? I've been using it myself when testing alternative configurations and I've never had any problems with it. If all you want to do is try Spacemacs it should be fine.

alias spacemacs="HOME=/.../ emacs"

[brabalan]

@d12frosted Thanks for the suggestion. The reason I want to have both active at the same time is that I'm not fully ready to switch to spacemacs. I do too much in emacs (especially reading mail) and I prefer to gradually switch.

[d12frosted]

@TheBB Hm. Well, probably it is good enough to just test spacemacs, but in a long run it could hurt. Especially if you have different things that use $HOME value.

@brabalan Ah, I see. Well, then in my opinion it's better to make working the thing you use for running emacs:

$ open /Applications/Emacs.app -n --args -Q --eval '(progn (setq user-emacs-directory "~/src/spacemacs/") (load-file "~/src/spacemacs/init.el"))'

[brabalan]

@d12frosted I think the pull request does what I want … but as I installed it in the develop branch, the code is not executed. I just tried it in master and it seems to work.

[justbur]

@brabalan #3391 doesn't seem adequate. What about other uses of async?

[justbur]

also this seems dirty, but you could try changing $HOME back after emacs loads

(setenv "HOME" "path/to/home")

[d12frosted]

@justbur Haha. Good idea! 😄

[brabalan]

@justbur What do you mean by other uses of async? I greped for async-start, excluding the ones in elpa:

% grep 'async-start' **/*.el | grep -v elpa
core/core-release-management.el:    (async-start
layers/+distribution/spacemacs/local/paradox/paradox.el:      ;; We have to do this with eval, because `async-start' is a
layers/+distribution/spacemacs/local/paradox/paradox.el:       `(async-start

The first hit is my proposed change, and the second one also does some variable injection manually (the macro async-inject-variable is basically a setq for a regexp):

       `(async-start
         (lambda ()
           (setq package-user-dir ,package-user-dir
                 package-archives ',package-archives
                 package-archive-contents ',package-archive-contents)

Regarding setting back $HOME, that's a way to get around the problem, assuming spacemacs only rely on $HOME for the location of .emacs.d at startup, and no longer rely on it to find .emacs.d after initialization (I'm worried that some variables may be set using $HOME after I've changed it back).

[justbur]

@brabalan You're right, but my point was more that we potentially have to worry about all current and future uses of async.

I don't mind your solution. I was just trying to come up with a better way of doing things. I was half joking with the $HOME thing. I don't think it's a great solution either.

It seems to me at least that the cleanest way to do this is to have a script that toggles symlinks like @d12frosted suggested, but I'll shut up now because this won't affect me as it is.

[brabalan]

@justbur I did not know of async till yesterday, and it seems we have to worry about it anyway (as in: any use of a variable defined outside of the async should be injected). Using scripts would work great if I did not need to run two emacs side by side.

[justbur]

@brabalan sorry I missed the part where you wanted two instances running at the same time

[justbur]

@brabalan Try setting $EMACSLOADPATH manually for the spacemacs session, as discussed here, along with your initial trick of setting the emacs directory variable. You're just trying to prevent emacs from knowing about your ~/.emacs.d

[oiwn]

yes, same problem. im using both prelude and spacemacs atm for the different projects.

[TheBB]

The fix is in the develop branch now. Incidentally it's not useful until release, since the async session in question doesn't happen on the develop branch...