this is caused by the home buffer loading build-in
org which conflicts with elpa org.
We actually want to use elpa org exclusively so we have
to make sure to redraw the spacemacs buffer only
after we have finished loading the layers.
In addition latest org version 9.6 and the behaviour
on emacs 29 has also changed so that org is autoloaded
much earlier than before. This is what actually did
make this bug show up.
However this behaviour was in place since a long time
and could be the cause for a lot of unreproducible
bugs as the actual conflicts are dependent on the
distribution specific emacs version.
Known issues:
This is a hotfix it solves the original issue but
introduces a new, hopefully less dangerous issue,
this is for now the start buffer is not configurable.
I will add a follow up PR to remove this issue however
I think this is far less annoying than a set of random
conflicts caused by loading elisp files from different org
sources.
The script used to identify and update the change is added into the GitHub
workflows script directory. A workflow action can be created to trigger the
script to update the headers on the first of every new year. Possibly a task for
a consequent PR.
* new function configuration-layer//stable-elpa-disable-repository
* new function configuration-layer//stable-elpa-update-version-file
* new function configuration-layer//stable-elpa-delete-temporary-files
* new function configuration-layer//stable-elpa-ask-to-continue
* new function configuration-layer//stable-elpa-verify-archive
* new function configuration-layer//stable-elpa-disable-repository
* rename function configuration-layer/stable-elpa-download-tarball to
configuration-layer//stable-elpa-download-tarball
* new function configuration-layer/stable-elpa-init
* make the function configuration-layer/stable-elpa-version interactive
configuration-layer/stable-elpa-init is called from init.el.
This function then calls the other new function in more clear fashion than the
previous complicated configuration-layer/stable-elpa-download-tarball
The users are now prompt if they want to install the stable ELPA repository when
the verification of the archive failed.
* 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.
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/")))
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!
Many people (including me) were confused when trying to install Spacemacs on an
outdated Emacs. A message was issued, but honestly nobody thinks of going to see
the *Messages* buffer when a perfeclty normal vanilla Emacs starts up,
especially not beginners.
This way, an error is visible and users can take corrective actions.
Maxi Wolff
Lin Sun
Codruț Constantin Gușoi
Arif Er
Lin Sun
syl20bnr
JAremko
Robert O'Connor
Carl Lange
Aaron Jensen
Tad Fisher
ZarsBranchkin
deb0ch
Eivind Fonn