See updated DOCUMENTATION.org and FAQ.org for more info.
* add core-env.el
* add library load-env-vars.el
* add bootstrap package dotenv-mode.el
* remove spacemacs-environment from bootstrap layer
* remove dotspacemacs variable dotspacemacs-import-env-vars-from-shell
* remove dotspacemacs variable dotspacemacs-improt-env-vars-shell-file-name
* add new key binding SPC f e e to open spacemacs.env file
* add new key binding SPC f e E to reload environment variable from env file
* add new key binding SPC f e C-e to re-initialize the env file from shell.
Distribute spacemacs-theme with Spacemacs so we don't need to download the
package of the theme at startup. It was delaying the display of the home buffer.
Now Spacemacs fallback to spacemacs-dark theme if the user theme cannot be
applied. Spacemacs then tries to install and reapply the user theme. If
successful, at the subsequent startups the user theme is applied right away
instead of spacemacs-dark. If the installation failed then we display a warning
informing the user and suggesting some actions.
There is now no package left to be installed manually at the start of Spacemacs.
This feels weird to set as default a variable using a third-party
service like Dropbox. Was OK when Spacemacs was less popular, now this
variable has nothing to do in this project.
With this new variable, user can load spacemacs anywhere, e.g.
"~/.emacs.d/spacemacs/". Only user's cache directory is still hard-coded
as "~/.emacs.d/.cache/". If user want to use spacemacs this way, drop
one line as the below in "~/.emacs.d/init.el":
(setq spacemacs-start-directory "~/.emacs.d/spacemacs/")
(load-file (concat spacemacs-start-directory "init.el"))
Now the user should use `SPC f e h` helm-spacemacs.
This is due to the fact that spacemacs layer is now a regular layer
stored in the "layers" directory.
