* new dotvariable dotspacemacs-emacs-pdumper-executable-file
* new dotvariable dotspacemacs-emacs-dumper-dump-file
* dump emacs if dotspacemacs-emacs-pdumper-executable-file is non nil
* 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.
Unfortunately preactivating yasnippet while dumping double the loading time.
Not sure why exactly the loading time doubles, it should no be the case.
So for now we only require the library and let the hook for activate it.
For now we have an issue with invalid XMP image format when dumping.
So we force utf-8 separator.
spaceline-compile is really long and not really necessary for regular users.
Advanced users must explicitly call spaceline-compile in their dotfile and be
ready to pay a 0.5s penalty when loading emacs.
The byte compiler doesn't know about `smartparens-strict-mode' because
smartparens is lazy loaded, so wrap the variable reference in `bound-and-true-p'
to silence a warning that appears on Spacemacs startup.
To reproduce:
1. Install a fresh Spacemacs from develop branch
2. Use spacemacs-base distribution
3. Select only these configuration layers: spacemacs-editing python
4. Restart Emacs to install packages
5. Restart Emacs again and observe warning:
Warning (bytecomp): reference to free variable 'smartparens-strict-mode'
Needs to use `pre-init` function in order to have the variable
spacemacs-web-beautify--modes to be populated before the init function of
web-beautify is actually called.
Before the display system is initialized, we cannot reliably make font
measurements so the height will be incorrect. This lead to display artefacts
if emacs was started in daemon mode without a graphical interface and later a
graphical client was connected (so for example, if you do `emacs --daemon`
followed by `emacsclient -c`).
