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.
Since Emacs 25.1 I got screen flickering when packages are installed on
startup.
Shuffling the UI elements removal seems to fix it on my system using X.
It may have the opposite effect on other users setup.
Thanks to the power provided by Lisp, hack package-install to patch on the
fly org and org dependencies installations in order to install org-plus-contrib
instead.
It is now possible to add local elpa repositories to private variable
configuration-layer--elpa-archives for instance:
(defvar configuration-layer--elpa-archives
'(("spacelpa" . "~/.emacs.d/.cache/spacelpa/"))
"List of ELPA archives required by Spacemacs.")
New functions:
- configuration-layer//package-archive-absolute-pathp
- configuration-layer//package-archive-local-pathp
Fix computation of package installation lazyness when the variable
dotspacemacs-enable-lazy-installation is set to all.
Improve methods on cfgl-layer class to be able to return a list of packages with
or without their properties.
Update tests to reflect the changes.
Discard the warnings produced when packages are byte-compiled which fix the
popup of the *Compile-Log* window at the end of the installation.
If emacs has been launch with argument `--debug-init` we don't discard the
warnings.
Function configuration-layer/load-or-install-package now correctly add the
installed packages to indexed-package hash map.
Those packages are put under the special layer `system`.
This is the first stone toward Spacemacs own ELPA repository.
New function configuration-layer/create-spacelpa-repository which creates the
archive-contents file for the Spacelpa repository containing all the ELPA
packages supported by Spacemacs (and only them).
The layer files were loaded twice because the global variable controlling
the loading of layer files was not explicity set at the layer discovery phase.
Enabling a company backend for a specific mode was a tedious tasks with code
scattered at different locations, one for local variable definitions, one for
company hook function definitions and another where the backends were pushed to
the local variables (which was problematic, since we ended up pushing the same
backends over and over again with `SPC f e R`, pushes have been replaced by
add-to-list calls in the new macro).
All these steps are now put together at one place with the new macro
spacemacs|add-company-backends, check its docstring for more info on its
arguments.
This macro also allows to define arbitrary buffer local variables to tune
company for specific modes (similar to layer variables via a keyword :variables)
The code related to company backends management has been moved to the
auto-completion layer in the funcs.el file. A nice side effect of this move is
that it enforces correct encapsulation of company backends related code. We can
now easily detect if there is some configuration leakage when the
auto-completion layer is not used. But we loose macro expansion at file loading
time (not sue it is a big concern though).
The function spacemacs|enable-auto-complete was never used so it has been
deleted which led to the deletion of the now empty file core-auto-completion.el.
The example in LAYERS.org regarding auto-completion is now out of date and has
been deleted. An example to setup auto-completion is provided in the README.org
file of the auto-completion layer.
spacemacs/alternate-window was suggested to switch between the last selected
window, or the window-analog of SPC TAB (spacemacs/alternate-buffer). This is
part of a larger family of functions, such as spacemacs/jump-to-last-layout on
SPC l TAB and eyebrowse-last-window-config on SPC l w TAB.
Resolves#7845
Some directories were added twice.
Make it more explicit in the code which directories we look into and filter out
directories that don't exist. Emit a warning if an unknown directory is
provided.
Given the loading process of Spacemacs we have no choice but to set the
custom settings twice:
- once at the very beginning of startup
- once at the very end of loading
The first application of custom settings is to be sure that Emacs knows all the
defined settings before saving them to a file (otherwise we loose all the
settings that Emacs does not know of).
The second application is to override any settings set in dotfile functions
like `dotspacemacs/user-config`, users expect the custom settings to be the
effective ones.
This double loading issue is independent from the managment method used for
custom settings. Even with a separate custom-settings file explicitly loaded in
the dotfile we would have been forced to load this file twice to acheive the
expected result described here.
Note: Loading custom-settings twice is not ideal since they can have side
effects! Maybe an inhibit variable in Emacs can supress these side effects?
New function `dotspacmacs/emacs-custom-settings` wrapping Emacs
custom settings sexps.
`dotspacemacs/emacs-custom-settings` is called just after the user
configuration (`dotspacemacs/user-config`)
Customize cannot write its auto-generated sexps inside a function, to
accomplish this we trick Emacs by setting the custom file to a file
in `.cache` directory, the path to this file is defined by the variable
`spacemacs--custom-file`. At the startup of Emacs we read this file
to insert its content inside the function
`dotspacemacs/emacs-custom-settings` in the dotfile, this is done in the
function `spacemacs/write-custom-settings-to-dotfile`.
I don't think we need to write the custom settings to the dotfile when
exiting Emacs as well, since we do it at startup at the very beginning
(i.e. before actually loading the dotfile) we should be OK.
Fixes#5170
When upgrading packages, Spacemacs backs up the old versions of the
packages and then tells the user to restart Emacs using `SPC q r` so
that the new version will be auto-installed. But `SPC q r` doesn't
work if restart-emacs is one of the packages which is being upgraded,
and hence isn't currently installed.
