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/")))
In this case Spacemacs won't write custom variables to the
dotspacemacs/emacs-custom-settings variable.
Move setq and add-advice to spacemacs/initialize-custom-file which is now
called in spacemacs/init function just after dotspacemacs/user-init function.
It is now possible to use package properties like :location in
dotspacemacs-themes.
Added hooks ran at the beginning and end of configuration-layer/sync:
- configuration-layer-pre-sync-hook
- configuration-layer-post-sync-hook
configuration-layer-pre-sync-hook is used to hook the new function
spacemacs//add-theme-packages-to-additional-packages. This new function updates
dotspacemacs--additional-theme-packages variables.
Update documentation to mention the new feature.
Add all theme packages defined in dotspacemacs-themes to the variable
dotspacemacs-additional-packages and delay the application of user theme at the
end of startup (only when user theme cannot be applied at the very beginning
of Emacs startup).
This has nice properties:
- we leverage the layer system to handle the theme packages installation and
cleanup.
- theme packages are automatically owned by the dotfile preventing them from
being garbage collected.
- the protected package mechanism is now obsolete since themes were the last
packages using it. This mechanism may be removed in a near future.
Thanks to TheBB for the initial idea.
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.
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.
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
This commit defines:
- spacemacs-default-jump-handlers: a list of functions that can jump to
definition in ALL modes.
- spacemacs-jump-handlers-MODE: a list of functions that can jump to
definition in MODE.
- spacemacs-jump-handlers: a buffer-local list of functions that can
jump to definition. This is made up of the values of the two previous
variables whenever a given major mode is activated.
- spacemacs/jump-to-definition: a function that tries each function in
spacemacs-jump-handlers in order, and stops when one of them takes us
somewhere new.
- spacemacs|define-jump-handlers: a macro that
* defines spacemacs-jump-handlers-MODE, possibly filled with initial
functions
* defines a function that is added to the hook of the given MODE
* binds “SPC m g g” of that MODE to spacemacs/jump-to-definition
This is an attempt to harmonize all the different approaches to jumping.
Specifically,
- Existing intelligent jump packages that work for only a single mode
should go to the beginning of spacemacs-jump-handlers-MODE. E.g.
anaconda for python, ensime for scala, etc.
- Packages like gtags that work for several modes (but potentially not
all) and which is dumber than the intelligent jumpers should go the
the END of spacemacs-jump-handlers-MODE.
- Packages like dumb-jump that work for all modes should go to
spacemacs-default-jump-handlers.
In all cases the order of the jump handlers in each list should be from
most to least intelligent.
Fixes#6619
Helm-flx, which is included as a core package, requires a minimum Emacs
version of 24.4. As it stands attempting to install Spacemacs on Emacs
24.3 or below will break on helm-flx.
Revert "Parse CLI args after dotspacemacs/init"
This reverts commit 0a35502de4.
We cannot delay the parsing of CLI params since we need their values
early during the loading process (i.e. debug info).
Replace the previous commit with a new variable `spacemacs-insecure`
which takes the value of --insecure boolean parameter.
spacemacs/report-issue opens a buffer prepopulated with a template and some
system information. The buffer is markdown-mode augmented with a keybinding to
send the contents to github.
Or if that doesn't work, the text remains in the buffer to be manually copied
and pasted. This makes the error reporting more robust: right after the user has
experienced one bug is the worst time to manifest another one.
This commit also rewrites spacemacs//describe-last-keys-string because I
couldn't figure out how else to prevent view-lossage from burying the new
REPORT_SPACEMACS_ISSUE buffer. Suggestions welcome.
