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/")))
Set it to emacs-version as it is the saner defaults here. When updating the
version of emacs, packages should be byte-recompiled. Thus this is safer to
isolate each package by emacs-version.
Change meaningful values of BACKWARD argument to just nil and non-nil.
Get rid of spacemacs--cycle-themes, it was unnecessary.
Create a defvar for spacemacs--cur-theme.
Original Commit List
- update cycle-spacemacs-theme function to work backward with universal arg
- add a transient-state hydra to cycle through the modes
- move the transient-state definition in the +distribution spacemacs-base
- refactor using hydra syntax for expression as command
- modified cycle-theme to handle negative command argument
- add keybing for helm-themes in the transient-state
Adds support for setting the following gruvbox theme variants
as dotspacemacs-theme:
- gruvbox-dark-soft
- gruvbox-dark-medium
- gruvbox-dark-hard
- gruvbox-light-soft
- gruvbox-light-medium
- gruvbox-light-hard
The default value is now at the distribution level. The user must put the ivy
layer explicitly in the dotfile.
This to be consistent with filetree package which is neotree by default in
the standard spacemacs distribution.
I'm afraid that we add too much wizard questions as the helm/ivy case will
happen more and more in the future. Neotree and Treemacs are the first layers
to follow the Helm and Ivy pattern. I don't want to add a fourth question to
the wizard which makes it heavy and is not as useful for new users.
Shadowing is now control by layer property ':can-shadow' only.
can-shadow is a commutative relation, if layer1 can shadow layer2 then layer2
can shadow layer1.
the shadow operator is a binary operator accepting two layer names, it is not
commutative and the order of the operands is determined by the order of the
layers in the dotfile (like the ownership stealing mechanism).
If ':can-shadow' is set explicity to nil in the dotfile then the layer won't
shadow any layer.
For instance to install both ivy and helm layer:
(setq dotspacemacs-configuration-layers
'(
ivy
(helm :can-shadow nil)
)
note that due to the commutative relation the above example can also be
written (in this case, ':can-shadow' should be read ':can-be-shawdowed'):
(setq dotspacemacs-configuration-layers
'(
(ivy :can-shadow nil)
helm
)
Layers can now declare in their layers.el file that they shadow one or more
layers using the following functions:
- configuration-layer/shadow-layers
- configuration-layer/shadow-layer
Those function are commutative so:
(configuration-layer/shadow-layer 'layer1 'layer2)
is the same as
(configuration-layer/shadow-layer 'layer2 'layer1)
and means that
layer1 shadows layer2
and
layer2 shadows layer1
The typical use-case is helm and ivy layers. Helm shadows the ivy layer and
Ivy shadows the helm layer.
Shadowing is sensitive to the order of declaration of layers in the dotfile,
for instance:
(setq dotspacemacs-configuration-layers '(
helm
ivy
))
means that ivy shadows helm so helm layer is effectively ignored,
whereas
(setq dotspacemacs-configuration-layers '(
ivy
helm
))
means that helm shadows ivy so ivy layer is effectively ignored.
This mechanism can be turned off using the :can-shadow keyword:
(setq dotspacemacs-configuration-layers '(
ivy
(helm :can-shadow nil)
))
means that both ivy and helm layers will be installed (not recommended in this
case)
Note that the `:can-shadow` mechanism will be fully implemented in a next
commit.
- remove variable configuration-layer--used-distant-packages
- rename function configuration-layer//get-distant-packages to
configuration-layer//filter-distant-packages to better reflect what it does
- Add argument PREDICATE to configuration-layer//filter-distant-packages
- New cfgl-package methods: cfgl-package-used-p and cfgl-package-distant-p
- Add unit tests
Add `(default X)` comment to almost all dotspacemacs variables in
dotspacemacs/init function in the template. Exempted are variables with long
default values. (e.g. dotspacemacs-themes)
Remove `(default X)` from doctsring of dotspacemacs variables. It isn't
necessary, the built-in help system already displays the default value
automatically.
Fix some minor grammar and spelling mistakes.
"micro-state" was the previous name for "transient-state".
Reword the sentence and quote the kill-ring variable.
Duplicate the docstring to the dotspacemacs-enable-paste-transient-state
variables docstring in core-dotspacemacs.el.
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!
