* new function configuration-layer//stable-elpa-disable-repository
* new function configuration-layer//stable-elpa-update-version-file
* new function configuration-layer//stable-elpa-delete-temporary-files
* new function configuration-layer//stable-elpa-ask-to-continue
* new function configuration-layer//stable-elpa-verify-archive
* new function configuration-layer//stable-elpa-disable-repository
* rename function configuration-layer/stable-elpa-download-tarball to
configuration-layer//stable-elpa-download-tarball
* new function configuration-layer/stable-elpa-init
* make the function configuration-layer/stable-elpa-version interactive
configuration-layer/stable-elpa-init is called from init.el.
This function then calls the other new function in more clear fashion than the
previous complicated configuration-layer/stable-elpa-download-tarball
The users are now prompt if they want to install the stable ELPA repository when
the verification of the archive failed.
* rename core-dump.el to core-dumper.el
* add function spacemacs/dump-emacs
* explicitly load core-dumper.el file in init.el
* asynchronously dump emacs if layer list has changed, see special buffer
*spacemacs-dumper* for the output.
Use the official spacelpa ELPA repository.
address: https://github.com/syl20bnr/spacelpa
ELPA repository configuration is now in a file called .lock at the root of the
git repository. Its goal is to setup the ELPA repositories for a given branch
and it should not be modified! The philosophy of Spacemacs is to never fork the
git repository and this lock file has been put in the repo on purpose.
Only the master branch will have a .lock file that points to spacelpa, the
develop branch won't use the stable ELPA repository and will continue to behave
like it always did.
BUT for testing purpose and until the first major version of Spacemacs that uses
the stable ELPA repo is released I push a .lock file to develop branch that
points to spacelpa.
I understand that some people can be annoyed by this so the variable
configuration-layer--elpa-archives can be overriden by putting a setq in your
dotfile in the user-init function like this:
(setq configuration-layer--elpa-archives
'(("melpa" . "melpa.org/packages/")
("org" . "orgmode.org/elpa/")
("gnu" . "elpa.gnu.org/packages/")))
Replace the optional argument `no-install` by a global variable named
`spacemacs-sync-packages`.
Rename the hooks to reflect the renaming of the function.
Rename the flag `--no-sync` to the more explicit `--no-package-sync`
This adds a new startup flag `--skip-sync`. It will force spacemacs to skip
package synchonization. This can be useful in cases when you're working under
poor or restrictive network.
Thanks, @zaript, for this idea!
Many people (including me) were confused when trying to install Spacemacs on an
outdated Emacs. A message was issued, but honestly nobody thinks of going to see
the *Messages* buffer when a perfeclty normal vanilla Emacs starts up,
especially not beginners.
This way, an error is visible and users can take corrective actions.
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"))
