The function: helm-org-get-candidates was removed upstream.
Improvements:
Recenter the target candidate.
Reversed the helm headings list, to match the order of the
questions in FAQ.org, so that the Common questions are
listed first.
Removed the : (colon) after the heading: How do I
in FAQ.org, to match the other parent headings.
The newly introduced function to compile an elpa package
was very much redundant with the existing recompile-elpa function.
I have adapted recompile-elpa so that it can be used for the helm action too.
In addition I have bound recompile-elpa to `SPC c C-c` to allow users to
easily recompile their entire elpa directory if the need arises.
I have also removed the error handling in the helm action in favor of
standard error reporting via the *Compile-Log* buffer.
How to use: `SCP h p` select package then `F3` or `C-z` and choose `Recompile`
Motivation: Some packages when compiling need other packages to be loaded first.
The pacakage maintainers should make sure of this requirement but sommetimes
they don't. It also doesn't help when Spacemacs is lazy loading and compiles
updated pacakges on startup. So the manual fix for this problem is recompile the
package once Spacemacs has fully loaded. This requires user go to the package
install location to delete elc files and then do a `spacemacs/recompile-elpa`.
This commit will do that chore for them.
This will make fixing the problem with `org-plus-contrib` or `dumb-jump` update
every now and then easier.
Getting FAQ candidates requires org to be loaded which in turn requires to
load magit (via orgit) etc...
This commit moves the FAQ helm source to a new feature helm-spacemacs-faq and
removes the FAQ source from SPC h SPC so the FAQs are only available as a helm
source via SPC h f.
But we have still the FAQ org file entry in SPC h SPC so it is easy to open
the file from the main help key binding.
I find myself wanting to open the package.el and f3 is just too far away
in my keyboard. And I thought maybe this would be something people might
want. Also maybe we could have special binding for actions? like `C-1`
`C-2`, etc
Fixes some edge cases like SPC f e R performed after SPC h SPC which
could wrongly install or uninstall packages.
Side effects is contained using the variable
configuration-layer--package-properties-read-onlyp, if non nil then
properties value of a package cannot be overwritten.
TL;DR Should get 20~25% speed improvement on startup, should get a big
improvement when using ivy or helm SPC h SPC. Users with layers.el files
in their layers must use `configuration-layer/declare-used-layer`
instead of `configuration-layer/declare-layer`
The implementation of the layer system made heavy use of `object-assoc`
and `object-assoc-list` functions which are not efficient. This PR
mainly replaces those object lists with hash maps in order to index the
objects by their name and achieve an O(1) access time.
The old object lists `configuration-layer--layers` and
`configuration-layer--packages` have been each by two variables each:
- `configuration-layer--indexed-layers` which is a hash-map of all the
layer objects and `configuration-layer--used-layers` which is a list of
all _used_ layers symbols,
- symmetrically `configuration-layer--indexed-packages` which is a
hash-map of all the package objects and
`configuration-layer--used-packages` which is a list of all _used_
packages symbols.
The hash map `configuration-layer--layer-paths` is gone, now we create
directly layer objects when discovering the layers and set the :dir
property. Note that previously the layer paths were the parent directory
of the layer, now :dir is the layer path.
The function `configuration-layer//make-layer` is now similar to its
counterpart `configuration-layer//make-package` in the sense that it
takes an optional `obj` to be able to override its properties.
The functions `configuration-layer/declare-layer` and
`configuration-layer/declare-layers` now takes an optional parameter
`usedp` in order to declare used or not used layers. For convenience
new functions have been added: `configuration-layer/declare-used-layer`
and `configuration-layer/declare-used-layers`, users _must_ update all
occurrences of `configuration-layer/declare-layer` by
`configuration-layer/declare-used-layers` in their `layers.el` files.
`helm-spacemacs-help` and `ivy-spacemacs-help` are updated to match the
changes in `core-configuration-layer.el`.
Rename some variables to make them more explicit:
`configuration-layer-no-layer` -> `configuration-layer-exclude-all-layers`
`configuration-layer-distribution` -> `configuration-layer-force-distribution`
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"))
As it was the case during the good old days when spacemacs was still a
baby, SPC h SPC now list correctly all the pre/init/post functions and
the associsted layer. It also now list properly the current owner of
a package so it is easy to find the owner of a package by narrowing
with `packagename owner`.
This new old functionality is possible by leveraging the last
improvements to the layer system (see previous commits).
TODO: update the sources for Ivy
